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

[Srikanth]

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

FWIW/FYI
Thanks
Srikanth

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.