RFR: JDK-8234729: Javac should eagerly change code generation for method references to avert IllegalAccessError in future.

Srikanth srikanth.adayapalam at oracle.com
Mon Nov 25 12:00:18 UTC 2019

Just as a curiosity/academic exercise, I instrumented javac to gather 
statistics on how many method references are encountered in a clean 
build of OpenJDK mainline tip and how many of those would trigger the 
problem scenario:

Total method references encountered: 1715
Ones that would trigger the problem scenario: 0


On 25/11/19 4:39 PM, Srikanth wrote:
> JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8234729
> Webrev link: 
> http://cr.openjdk.java.net/~sadayapalam/JDK-8234729/webrev.00/jdk.patch
> [1] Hidden Classes JEP: http://openjdk.java.net/jeps/8220607
> [2] Corresponding JBS ticket: 
> https://bugs.openjdk.java.net/browse/JDK-8220607
> [3] Nestmates branch specific fix: 
> https://bugs.openjdk.java.net/browse/JDK-8227415
> Scenario: Javac's code generation for method references that target a 
> protected method declared in a superclass in a different package.
> Problem:
> When Hidden Classes JEP [1] eventually makes its way into mainline via 
> [2], due to stricter enforcement of access control, code compiled 
> using earlier compilers that uses method references that target a 
> protected method of a super class in a different package may trigger 
> an IllegalAccessError.
> This was discovered in the nestmates work in Valhalla and was fixed 
> locally there via [3].
> The present task JDK-8234729 is to bring forward the fix in 
> JDK-8227415 [3] to jdk/jdk ahead of time, so as to minimize 
> compatibility risks. If [2] and [3] were released together, then any 
> code compiled using older compilers that involves the scenario may 
> trigger an IAE and will have to recompiled.
> More detailed description in 
> https://bugs.openjdk.java.net/browse/JDK-8234729
> The proposed fix passes all langtools tests and JCK tests.
> Thanks
> Srikanth.

More information about the compiler-dev mailing list