New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't call methods of private subclasses with java_method in java 12 #5841
Comments
Looks like this is a problem with how we determine whether we should set methods accessible. The logic here basically turns off setAccessible when on Java 9 or higher:
I'm going to look at changing this property back to always true and modify the logic that uses it to use our trySetAccessible logic. |
It looks like all places that use the JI_SETACCESSIBLE option (with the default "false" on Java 9+) are already using our safe trySetAccessible that's aware of modules. Changing this calculated default to "true" appears to work fine. I'm going to push it to a PR to make sure it doesn't affect too much other code. |
The logic previously was depending on the ji.setAccessible property, which by default would simply refuse to set accessible *at all* when the Java version was >= "1.9" (also showing this logic was introduced very early in the Java 9 development cycle.) That default is removed here, along with a the CAN_SET_ACCESSIBLE static field in RubyInstanceConfig deprecated and replaced with the original meaning of this property, simply whether to attempt setAccessible. The direct calls to setAccessible have been replaced by the trySetAccessible in backport9 library that checks if the target member's module is open to JRuby, allowing users to opt-in to that reflective access if their application needs it. Previously these cases still skipped setAccessible just due to being on Java 9+. Most of the changes here were masked by the property, but I have also fixed several others that were not guarded by the property or that were otherwise used in booting JRuby or extending Java integration. This fixes jruby#5841 by allowing `java_method` Method objects to go ahead and trySetAccessible when the module is open. This relates to jruby#5821, which fixed in 9.2.8 a similar issue where even an open module would not set fields and methods accessible.
The logic previously was depending on the ji.setAccessible property, which by default would simply refuse to set accessible *at all* when the Java version was >= "1.9" (also showing this logic was introduced very early in the Java 9 development cycle.) That default is removed here, along with a the CAN_SET_ACCESSIBLE static field in RubyInstanceConfig deprecated and replaced with the original meaning of this property, simply whether to attempt setAccessible. The direct calls to setAccessible have been replaced by the trySetAccessible in backport9 library that checks if the target member's module is open to JRuby, allowing users to opt-in to that reflective access if their application needs it. Previously these cases still skipped setAccessible just due to being on Java 9+. Most of the changes here were masked by the property, but I have also fixed several others that were not guarded by the property or that were otherwise used in booting JRuby or extending Java integration. This fixes jruby#5841 by allowing `java_method` Method objects to go ahead and trySetAccessible when the module is open. This relates to jruby#5821, which fixed in 9.2.8 a similar issue where even an open module would not set fields and methods accessible.
yamam commentedAug 20, 2019
Environment
jruby 9.2.8.0 (2.5.3) 2019-08-12 a1ac7ff OpenJDK 64-Bit Server VM 12.0.2+10 on 12.0.2+10 +jit [mswin32-x86_64]
JavaTest.java
test.rb
Expected Behavior
You can call methods of private subclasses with java_method in java 8.
Actual Behavior
You can't call methods of private subclasses with java_method in java 12.
The text was updated successfully, but these errors were encountered: