JDK-8019183 : Trying to get spliterator from a stream via method reference leads to java.lang.IllegalAccessError: tried to access class java.util.stream.BaseStream
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.stream
  • Affected Version: 8
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2013-06-26
  • Updated: 2013-09-05
  • Resolved: 2013-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Resolved
Related Reports
Duplicate :  
JDK-8023558 - Javac creates invalid bootstrap methods for complex lambda/methodref case
Relates :  
JDK-8023558 - Javac creates invalid bootstrap methods for complex lambda/methodref case
Description
Using construct like "streamSupplier.get()::spliterator" in a lambda expression leads to

Exception in thread "main" java.lang.IllegalAccessError: tried to access class java.util.stream.BaseStream from class IllegalAccessErrorTest$AllTests
	at IllegalAccessErrorTest$AllTests.lambda$2$bridge(IllegalAccessErrorTest.java:25)
	at IllegalAccessErrorTest$AllTests$$Lambda$3.get(Unknown Source)


If method reference is not used no exception is thrown.

Please see the source attached for reproduction of the issue.
It definitely could be simplified as it has a trace of JCK's test frameworks.

The problem could be seen on both JDK8b94 and JDK8b95-lambda.

Plenty of  JCK tests fail due to this issue, currently a "use-lambda-not-methodref" workaround is applied in the tests.

Please redispatch this issue to compiler or VM as needed.
Comments
See the following thread for more context: http://mail.openjdk.java.net/pipermail/lambda-dev/2013-January/007715.html
22-08-2013
Not sure whose fault is it, runtime or compiler. I've filed a bug against compiler: https://bugs.openjdk.java.net/browse/JDK-8023558
22-08-2013
Minimized testcase: interface SAM<T> { T get(); } public class Test { public static void main(String[] args) { SAM<SAM> sam = () -> Object::new; SAM temp = sam.get()::get; } }
22-08-2013
This case deserves be transformed into a JCK compiler/lang test.
22-08-2013
This *particular* failure goes away when BaseStream becomes public. But the general problem may still be there -- that a method ref to a public member of a nonpublic supertype may fail. For similar situations, such as super:: method references, the compiler generates a "bridge" and uses a method ref to that instead; this is similar to accessibility bridges. We should probably add method refs of this type to the list of things getting that treatment.
21-08-2013