to get your test case to the point where it fails I applied follow patch

diff --git a/src/main/java/fi/relex/SimpleClassImpl.java b/src/main/java/fi/relex/SimpleClassImpl.java
index 4ea0874..db6978c 100644
--- a/src/main/java/fi/relex/SimpleClassImpl.java
+++ b/src/main/java/fi/relex/SimpleClassImpl.java
@@ -1,10 +1,10 @@
 package fi.relex;

-public class SimpleClassImpl extends SimpleClass {
+class SimpleClassImpl extends SimpleClass {

     private final long value;

-    public SimpleClassImpl(long value) {
+    SimpleClassImpl(long value) {
         this.value = value;
     }

i.e. it is the https://github.com/jmiettinen/jruby-test/blob/master/src/main/java/fi/relex/BrokenClassImpl.java#L15 has a package private Builder whereas https://github.com/jmiettinen/jruby-test/blob/master/src/main/java/fi/relex/SimpleClassImpl.java#L16 is public

weird! I would not ever thought that the bootclassloader can help here - good catch.

Yeah, that's the thing that makes the difference. I should've brought it up more clearly.

As such, being on boot classpath should not have any effect on this as reflection should be able to reach and call both of the classes.
But with JRuby method resolution there seems to be.

Now that I think of it, we've been hit by JRuby being unable call methods from package-private classes before as we're deploying to Tomcat without adding JRuby to boot classpath there.

The difference seems to stem from the fact that in JavaUtil there's a check for suppressAccessChecks permission. If that check fails, the code concludes that it cannot call AccessibleObject#setAccessible. This check will succeed if JRuby is in boot classpath and fail otherwise.

This is not true at least if there's no SecurityManager present.

My colleague did some digging and it seems that @headius introduced first ban to not use methods from private classes: ec8d280 as a fix for JRUBY-4799.

This ban seems to have been loosened a bit later on and public methods for private classes are added if JavaUtil.CAN_SET_ACCESSIBLE is true.

I am not very familiar with how the AccessController should be used, but the current usage doesn't seem to match what happens in AccessibleObject#setAccessible.
There code first checks if there is a SecurityManager set and only if so calls SecurityManager#checkPermission(Permission) that delegates to the same AccessController#checkPermission(Permission) as the code in JavaUtil does.

@jmiettinen thanks for the analysis ... your logic totally makes sense, I think there are 2 issues to fix :

• change

  jruby/core/src/main/java/org/jruby/javasupport/JavaUtil.java

  Line 102 in 974bafb

  AccessController.checkPermission(new ReflectPermission("suppressAccessChecks"));

  to do some real code to check accessibility

• secondly, different methods being installed based on accessibility is quite a 'surprising' feature, JRuby should at least warn or figure out a uniform way to install and than fail at inaccessible methods at call-time (this is not something fixable in a patch release as it needs compatibility)