RFR: 8220607 Draft JEP: Hidden Classes

Mandy Chung mandy.chung at oracle.com
Tue Dec 10 06:29:37 UTC 2019

On 12/9/19 5:28 PM, forax at univ-mlv.fr wrote:
> On 12/9/19 3:19 PM, Remi Forax wrote:
>> 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.
> yes, and so currently, i can replace all my use case of unafe.defineAnonymousClass that doesn't use the constant pool patching.

thanks for the news.
>> http://hg.openjdk.java.net/valhalla/valhalla/file/eee025d47c8a/src/hotspot/share/ci/ciField.cpp#l215
> I vote for not allowing setAccessible/JNI to work on final fields of hidden classes. I don't want to have to think about a framework/library that will change my adapter fields at runtime.

That was the restriction I initially proposed but existing framework is 
impacted by this.   Such compatibility concern is not low.   On the 
other hand, "sealing up" the field or method from reflection is only 
useful for non-hidden classes as well.   John calls this "a locked 
class" a separate feature.   I do want the "locked class" feature as well.

I was pondering a little bit.  Perhaps we should make Field::set fail on 
a hidden class's final field ignoring the accessible flag. I have to 
look into this in particular custom serialization would need to continue 
to work.


More information about the valhalla-dev mailing list