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

[Maurizio Cimadamore]

Hi Srikanth,
the patch looks good, and I see no reasons as to why we shouldn't move 
forward with it. The real issue will be, of course, upgrading the 
runtime support to use hidden classes (instead of Unsafe.dAC) - at which 
point we might start see issues for code that has not been recompiled 
with your patch; but given that (a) the condition seems rare (as your 
number show) and (b) the workaround is easy (recompile!), we should 
probably not worry too much about this.

Cheers
Maurizio

On 25/11/2019 12:00, Srikanth wrote:
>
> 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.
>