In #4266, we noticed a difference what methods JRuby finds in Java-classes between JRuby-jar being in boot classpath and in the normal classpath. This change removes that difference.
The reason for the difference is that all classes in boot classpath are privileged and AccessController#checkPermission(Permission) will always return true to them, whereas for others the result depends on security policy in effect.
In normal (at least Oracle) JVM installations, the policy doesn't allow suppressAccessChecks, but call to AccessibleObject#setAccessible(boolean) will still succeed as there's no SecurityManager set.
I posit that trying to call setAccessible is a better way to see if we might later on succeed in calling setAccessible than checking the permission.
Test if we can set accessible by trying to call AccessibleObject#setA…
…ccessible(boolean) instead of seeing if we have permission 'suppressAccessChecks'. We may not have that permission if we're not using a privileged classloader but can still setAccessible if (when) there's no security manager
I like the idea, but perhaps we should test it against a class in JRuby, so we're not modifying permissions for a globally-visible class. Perhaps make an Integer look-alike static inner class and use that?
Check accesibility through a class that's in our control
Calling Field.setAccessible(boolean) only overrides the accessibility checks for that Field-object.
It is, however, better to do checks for code that's under our control. I don't know what would be the best place to insert such class so I dumped it into same package for now.
This looks fine to me...I'll merge. Thanks!