RFR: 8220607 Draft JEP: Hidden Classes

Mandy Chung mandy.chung at oracle.com
Mon Dec 9 23:51:15 UTC 2019

On 12/9/19 3:19 PM, Remi Forax wrote:
>> My memory is hazy on this: I thought the same trigger (package of the lookup
>> class) for whether those compiler-based annotations were allowed was the same
>> trigger for whether final fields were trusted.  So I had some slight concern
>> that replacements with the public methods in the JDK for code within j.l.lnvoke
>> (bootstrap methods etc) might affect final field behavior.
> For anonymous classes created using unsafe.defineAnonymousClass, final fields of all of them are considered as trusted, independent of if the host class is in java.lang or not.
> This is a very important property for adapter codes (generated dynamically) in a dynamic language because it means that if the adapter is constant (bound in a method handle tree in my case) then all the field access will be replaced by constants so the whole code will be constant folded. I rely on this property heavily.
> If hidden classes have not that property, it means that hidden classes are useless for me and that people will see perf regressions if they are using lambdas stored in static final fields if lambdas starts to use hidden classes instead of anonymous classes.

FYI.   In the current prototype, it does trusted the final fields of 
hidden class but we have to re-examine it from the specification 
perspective and also serialization.


[1] https://bugs.openjdk.java.net/browse/JDK-8235602

More information about the valhalla-dev mailing list