Explicitly request access before Lookup.find*#8989
Merged
headius merged 2 commits intojruby:masterfrom Sep 2, 2025
Merged
Conversation
The Lookup acquired from MethodHandles.lookup appears to produce IllegalAccessException for cases that publicLookup does not. This appears to be due to a JDK bug, but we can work around it by' explicitly requesting read access to the target class's module. There have been similar bugs relating to the use of MethodHandles.lookup versus MethodHandles.publicLookup. The most recent bug was filed in jruby#8987. Related JRuby bugs and an OpenJDK bug filed by me are also referenced from there. There's also a link to an OpenJDK core-libs-dev thread about this issue. The change here requests read access from the JRuby module to the module of the target class, avoiding the accessibility issue for classes that should otherwise be readable. There may be additional overhead in acquiring the MethodHandle this way. Fixes jruby#8987.
headius
force-pushed
the
another_public_lookup
branch
from
ca64cc8 to
b7c16fa
Compare
headius
changed the title
Member
Author
|
needs tests |
headius
added a commit
to headius/jruby
that referenced
this pull request
Sep 5, 2025
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.
headius
added a commit
to headius/jruby
that referenced
this pull request
Sep 5, 2025
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Edit: a previous version of this patch attempted to switch these lookups to
publicLookup(), but that broke several tests and internal logic that needed "more than public" access. The new patch was proposed by our friends on the core-libs-dev OpenJDK list.The Lookup acquired from MethodHandles.lookup appears to produce
IllegalAccessException for cases that publicLookup does not. This
appears to be due to a JDK bug, but we can work around it by'
explicitly requesting read access to the target class's module.
There have been similar bugs relating to the use of
MethodHandles.lookup versus MethodHandles.publicLookup. The most
recent bug was filed in #8987. Related JRuby bugs and
an OpenJDK bug filed by me are also referenced from there. There's
also a link to an OpenJDK core-libs-dev thread about this issue.
The change here requests read access from the JRuby module to the
module of the target class, avoiding the accessibility issue for
classes that should otherwise be readable. There may be additional
overhead in acquiring the MethodHandle this way.