Thanks for the report! Things did indeed change regarding how we handle Java modules in JRuby 9.2.9.0...it's likely that we're avoiding a setAccessible call because it would produce a warning, but for whatever reason proceeding to make the call anyway and causing this error.

A workaround for you would be to add this JVM flag:

--add-opens java.base/java.util.stream=org.jruby.dist

This will open up that package for reflection.

I notice that the error seems to original within the neo4j Ruby driver, so this may be something that needs to be fixed upstream.

Oh to be clear about the main change in 9.2.9... instead of eagerly setting Java classes and methods to be accessible, we now first query to see if the package is "open" for that sort of operation. The alternative is to go ahead and do it but produce warnings...which then get reported as bugs of a different sort. 🙄We're still trying to find a happy medium here.

This looks to be a problem of selecting the wrong target method signature. We should be invoking the Stream interface's forEach, both of which are public. Instead we attempt to invoke ReferencePipeline class's version, but that class is not public. As a result we get an error, since we're trying to call the non-public class's version of the method.

There's logic in our method binding to prevent this for concrete classes (pick the superclass method that is actually public/public) but perhaps we're not doing that effectively when the super signature is on an interface.

Reproduced with a trivial Spliterator implementation:

class MySplitter
  include java.util.Spliterator

  def tryAdvance consumer
    true
  end

  def trySplit
    nil
  end

  def characteristics
    0
  end
end

s = java.util.stream.StreamSupport.stream(MySplitter.new, false)

s.forEach {|x| p x}

Which yields:

$ jruby spliterator.rb 
TypeError: illegal access on 'forEach': class org.jruby.javasupport.JavaMethod (in module org.jruby.dist) cannot access a member of class java.util.stream.ReferencePipeline (in module java.base) with modifiers "public"
  <main> at spliterator.rb:19

Confirmed the above --add-opens flag does remedy the error.

I believe I see the problem.

In 02c5040 I removed logic we used to probe for a coarse-grained security restriction on setting classes accessible. Unfortunately I replaced it with a simple boolean.

As a result, the code at

This would probably have been caught with better testing on Java 11. We need to remedy that for JRuby 9.2.10.

The fix is fairly trivial; go back to the original logic that only attempted to bind methods from public classes.

@kares @enebo A possibly better fix would be to go ahead and bind methods from non-public classes if their package is open to us, but I have worries about that causing non-public methods to get bind that should not be callable. It seems like for normal dispatch we may not want to go this far.

We probably do want to go this far for super invocation from subclasses, but this is only one of many problems with the current Java class extending logic in JRuby.

I will commit the simple fix for now.

@headius We have a similar error in our application when using JRuby 9.2.9.0 with Java 11:
java.lang.management.ManagementFactory.getOperatingSystemMXBean.getTotalPhysicalMemorySize raises:

TypeError:
  illegal access on 'getTotalPhysicalMemorySize': class org.jruby.javasupport.JavaMethod (in module org.jruby.dist) cannot access class com.sun.management.internal.OperatingSystemImpl (in module jdk.management) because module jdk.management does not export com.sun.management.internal to module org.jruby.dist

This method call was working fine using JRuby 9.2.8.0 with Java 11.

Is the root cause of this the same as in this issue?

Did some further investigation and it seems that the method lookup on JRuby 9.2.9.0 is returning the wrong method:

jruby-9.2.9.0 > java.lang.management.ManagementFactory.getOperatingSystemMXBean.method(:getTotalPhysicalMemorySize)
 => #<Method: Java::ComSunManagementInternal::OperatingSystemImpl#getTotalPhysicalMemorySize>

But on JRuby 9.2.8.0 it was returning the method from a different class:

jruby-9.2.8.0 > java.lang.management.ManagementFactory.getOperatingSystemMXBean.method(:getTotalPhysicalMemorySize)
 => #<Method: Java::SunManagement::OperatingSystemImpl#getTotalPhysicalMemorySize>

@rsim Yes, it does seem like the same issue. I did not commit because I made the change immediately before RubyConf and it did not pass a quick local test. I'll take care of that today and get it into a PR.

@headius I just wanted to comment that I found a workaround that instead of

java.lang.management.ManagementFactory.getOperatingSystemMXBean.getTotalPhysicalMemorySize
# => TypeError (illegal access on 'getTotalPhysicalMemorySize': class org.jruby.javasupport.JavaMethod (in module org.jruby.dist) cannot access class com.sun.management.internal.OperatingSystemImpl (in module jdk.management) because module jdk.management does not export com.sun.management.internal to module org.jruby.dist)

I can use

os = java.lang.management.ManagementFactory.getOperatingSystemMXBean
method = os.java_class.interfaces.first.java_method "getTotalPhysicalMemorySize"
method.invoke(os)
# => 34359738368

As I see

os.java_class
# => class com.sun.management.internal.OperatingSystemImpl
os.java_class.interfaces.first
# => class com.sun.management.UnixOperatingSystemMXBean

and on Java 11 I cannot access classes and methods from the package com.sun.management.internal but I can access them via interface from the package com.sun.management.

@rsim Good find! Thanks for reporting back.

Fixed by #5984.