Use all the tricks to properly eliminate illegal access warnings #6195
Conversation
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
Because all modules will report isOpen => true when called from the unnamed module, we need a different way of accessing them. This logic makes two changes: * Use Lookup to acquire a method handle rather than using the reflected object. This allows to be sure we now have a fully accessible mechanism for accessing the related field or method, without triggering any warnings. Lookup.unreflect* will raise an exception if the reflected object is not already accessible, rather than a warning we cannot detect. * Use addOpens to attempt to *really* make the pseudo-open packages be open. This allows us to proceed to setAccessible knowing the package has moved from "kinda-sorta-open" to really open. The fallbacks here occur in the following cases: * If we cannot acquire a reference to a non-standard JDK class, like those in sun.nio.ch. This should not ever fail; reflecting against these classes is always permitted. * If we cannot acquire the method or field in question because it is not there. Again this should not fail under normal circumstances. * If we cannot unreflect a handle and cannot addOpens for the package in question.
12507f7 to
5473e0a
Compare
5473e0a to
9a40173
Compare
|
👍 very interesting, falsely assumed the runtime |
|
@kares It's pretty silly if you ask me. If you're running from the classpath (not the module path) these core JDK classes will claim to be open, but then actually warn because you're not supposed to access them. Adding via |
|
Retarget to 9.2.12 since this is largely zero-cost and cleans up most remaining warnings in JRuby proper. See #6285. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR attempts to tweak all of our uses of
setAccessiblefor accessing internal JDK classes to do the "right thing", be that using method handles,addOpens, or other tweaks to open up these classes if we legally can or fall back gracefully to degraded functionality without warnings.The general strategy is described in the first commit to FilenoUtil, but I summarize it again here:
Module.addOpensto make it really open, which then gives us a workable method handle and no warning output.Much of this is to deal with the unfortunate fact that our current check,
Module.isOpen, will always return true for the unnamed module but still warn when you set it accessible. This "kinda-sorta-open" state is a bug in my opinion, but at least explicitly usingaddOpenspromotes it to a fully-open state with no warnings.I will endeavor to eliminate all warnings in all modes with as little fallback as necessary.