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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Nov 25 12:53:02 UTC 2019

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.


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
> 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.

More information about the compiler-dev mailing list