| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
We should not attempt to read public classes from modules that are not readable from the JRuby module. Alternative fix for jruby#8987. Original fix in jruby#8989 approached this differently by requesting read access to the module. Further discussion in the related OpenJDK core-libs-dev thread lead to the realization that the generated proxy class from jruby#8987 was in an internal JDK module and not intended to be readable by anyone, but we were attempting to find it. The fix here avoids binding classes from modules that are not naturally readable from the JRuby module, rather than trying to add more reads than were originally configured or requested.
Modules that are not naturally readable should not be added to reads just so we can get access to their methods. Any logic that is passing unreadable modules' classes and methods to this logic should reexamine how those classes and methods are being acquired, and add reads at that point or avoid acquiring references to such unreadable modules. See jruby#8989 for the original patch, as a fix for jruby#8987. The OpenJDK core-libs-dev discussion linked from that issue led us to a new fix that avoids binding unreadable modules' classes in our Java integration layer.
| Back | FazBrowse Home | New Git URL |
This PR is an alternative (and probably more correct) fix for #8987, and does the following:
This fixes the issues in #8987 without adding new module reads for every method handle acquisition.
See the following OpenJDK core-libs-dev discussion for details: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151017.html