Comments (6)
Hello! If you use the default driver these architectures should already be supported because this type of driver is pure Java based and doesn't use the native module. But if you use the other drivers (dynamic, hybrid and native) you also need to compile the native module for the relative architecture. I would like to compile the native module for aarch64 but I need to understand how to do it (GitHub action seems that doesn't have an aarch64 environment): if you are able to compile native code on aarch64 can you explain to me via Skype how to compile it?
from jvm-driver.
I see. I was naively assuming that things like Modules.exportAllToAll()
was relying on the native module and "strong encapsulation" not being enforced for JNI, but upon closer inspection I see that method handles and runtime bytecode compilation of e.g. AccessibleSetterInvokerForJDK9.bwc
is used to circumvent these restrictions. Maybe my question should rather be how this works. As a potential user I'd like to understand the mechanism that enables circumvention of encapsulation and so better be able to reason about circumstances in which this might not work, whether this is likely to continue working in the future, etc.
from jvm-driver.
As you can see there are 4 types of drivers and the native driver works without tricks and taking full advantage of the JNI function which, as you already know, has no restrictions. The default driver fully uses the java code and the *.bwc files also correspond to the java classes that you can find in the java hook project. Explaining how the strong encapsulation is bypassed is a bit complex and relies not on one mechanism but on a number of mechanisms. Unfortunately I cannot guarantee that the default driver will work forever and for now it works for all java versions up to 19 ea. The native driver, on the other hand, is tied to the JNI interface and as long as this does not undergo revisions this type of driver will continue to work. The purpose of the driver is not to guarantee the functioning of the java code forever, but to give the possibility to those who have found software no longer working since JDK 9 to extend its life a little more. As for the native driver unfortunately at the moment I am not able to compile the native module for other platforms but if you or any other person could do it they would be welcome
from jvm-driver.
Thanks for explaining. I agree with the goals of this project and the fact that it cannot be guaranteed to work forever. I also appreciate that the pure java circumvention is complex. This makes me even more curious as to how the different pieces come together and having this described would be valuable for users to understand failure modes as well as general knowledge spreading, especially if contributions to this project are desired. Even a terse description of just the key tricks would be much appreciated.
I see that the hooks are compiled as if they were part of the jdk packages, but not sure why using e.g. AccessibleSetterInvokerForJDK9 doesn’t fail at runtime. Is that where using Unsafe.defineAnonymousClass to load them helps?
from jvm-driver.
Thanks for explaining. I agree with the goals of this project and the fact that it cannot be guaranteed to work forever. I also appreciate that the pure java circumvention is complex. This makes me even more curious as to how the different pieces come together and having this described would be valuable for users to understand failure modes as well as general knowledge spreading, especially if contributions to this project are desired. Even a terse description of just the key tricks would be much appreciated.
I see that the hooks are compiled as if they were part of the jdk packages, but not sure why using e.g. AccessibleSetterInvokerForJDK9 doesn’t fail at runtime. Is that where using Unsafe.defineAnonymousClass to load them helps?
Ok, I will explain it to you but privately via Skype or Whatsapp: send me your references to the email [email protected]
from jvm-driver.
I added support for aarch64 in the new version but it needs testing. I close the issue and if there are problems at runtime with the loading of the library for the aforementioned architecture, open a new issue
from jvm-driver.
Related Issues (7)
- Dependent libraries are absent on windows HOT 9
- Short field handlers are absent in NativeExecutor HOT 20
- Add prefix/suffix to 'jvm-driver' artefact name HOT 1
- NullPointerException when trying to initialize the driver in uber jar HOT 8
- Support more OS and arch? HOT 3
- jvm-driver-8.15.0 detected as Trojan by BitDefender (Probably False Positive) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jvm-driver.