Core upgrade#1367
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| String[] parts = line.split("\\s+"); | ||
| if (parts.length >= 2) | ||
| { | ||
| ENTITIES.put(parts[0], Integer.parseInt(parts[1])); |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1367 +/- ##
==========================================
- Coverage 86.20% 85.97% -0.23%
==========================================
Files 112 112
Lines 10277 10302 +25
Branches 4046 3962 -84
==========================================
- Hits 8859 8857 -2
- Misses 812 835 +23
- Partials 606 610 +4
🚀 New features to boost your workflow:
|
|
@marscher I am not sure if we should make the module org.jpype or just jpype for this jigsaw update. Whatever we use we will be stuck with it as you must open to our module. It appears there are two potential ways we can operate under jigsaw. The piece meal method is safer but requires the start JVM to manually add each an every module to be used to opens. It took me quite a while to find the right combination to operate. And that means a user is going to quickly find themselve getting random errors. I thus upgraded many points to being very verbose severe error logs so we don't get silent errors and bug reports. The second method would be to add a "trusted" flag to starting JPype. With that we would attempt to patch java.base to extend all access privileges to Python. I would then need to test to see if it gets respected. While it is good that we are now operating more in the Java security model, I fear it will make it harder for users to just operate as a simple local bridge like they expect. |
|
Even considered the downsides I have a gut feeling that the second method is kind of a hack and it seems foreseeable that it will fail in the future (of JVM development). Or is there a documented way of achieving it? As for the module name I'd go for org.jpype |
|
The reality of the Python ecosystem makes runtime module patching even more dangerous. Packages like JayDeBeAPI (and many others heavily promoted by AI models) blindly wrap JPype and invoke startJVM() inside opaque init() functions. The only structural advantage of a --patch-module strategy is that third-party packages inherently trust and export to java.base, meaning code injected there theoretically inherits whatever access those packages grant to the core runtime. In other words we can gain trust by installing in another module, but that doesn't allow us to change permissions. Java is a ONE AND DONE security model. Because we cannot stop wrappers from blindly locking down the JVM, trying to engineer a 'trusted flag' hack inside the Java boot layer is a dead end. Instead, we must focus heavily on making org.jpype cooperative:
As for how Dynamic class loader will work, is that room will need to be opened to us an all jar loads will have to join that room. Long term we will need to be more clear that packages are not applications and should not be starting the JVM. Only the main application should do that. |
|
I have tried to come up with a more sane method of dealing with modules and paths. The problem is as a bridge our users want to use the files the directed is to. So the assuming is on the path use it. But jigsaw expects a DAG of relationships to be formed. After jvm is loaded you can see the DAG, but it is too late do change configuration. My current direction is exposing all the raw jigsaw flags to the user. But even basic testing I found myself having to restart and add something as a new random error popped up. Darn no permissions for that. Suddenly the user must manage 2 paths and know JPSM. One AI proposal is to give a path and module list. We have a user cache file that contains all the known DAG elements. If something on the path appears that we don't know about then we use python zipfile to get its opens and requirements list. We then look at the modules the user requested and grant opens as needed so jpype can access those and any dependent module. This gets cached so we only need to learn deps once until a jar changes. So we would have path list, an option that tells where we want to look and a modules list. If the users says modules="*", they are saying just figure it out I just want to program, not be an enterprise manager. Benefits are we only need one path for modules and classes. The system will know which jar is a module abd which is a plain old class. It will also make the required choices. If they name a jar file on modules required and the module name in the jar is different or it is in unnamed we will just figure out the switches instead of forcing every user to become a JPMS expert. The downside is if a user places a huge directory on the path we are scanning everything to find one needle every startup. And the cache can become corrupted. On the flip side, we risk the XKCD outcome of well the developer is struggling with 2 paths, let's just give them a third to make it easier! Not sure there is a good direction or even a model we can point to that solves this well. |
|
There is a frame imbalance in this PR that will need to be address. |
3 participants
Pull Request Summary: JPype Reverse Bridge & Modular Infrastructure
This PR implements a significant architectural overhaul to support Java's Module System (Jigsaw) while maintaining compatibility across the "Broken Land" of Java 9 through 21.
Core Infrastructure & Module Support
org.jpypeto use formal module support. This includes providing the necessary module-path arguments and permission flags internally duringstartJVM.--add-opensand--add-readsflags (e.g.,java.base/java.lang=org.jpype). This abstracts away the complexity of Jigsaw security, ensuring the bridge "just works" without user-side flag management.Class.getResourceAsStream). This ensures internal assets are accessible even when the JAR is encapsulated as a named module.Proxy & JNI Performance Enhancements
getDefaultHandlebridge to handle default method invocation. This utilizes JNI to bypass the "Strong Encapsulation" restrictions that previously blocked proxies from accessing default methods in foreign modules.JDK 21+ Compliance Note
--enable-native-access=org.jpype. To avoid "poisoning" the startup of legacy JVMs (which do not recognize this flag), the bridge currently prioritizes universal compatibility. Future iterations may include a C++-level "probe" to safely apply this flag only when supported by the loaded DLL.The last one requires a bit of work as version probing is not something Java does well.
This PR should likely target JPype 1.8.
Fixes #1369