RFR: 8220607 Draft JEP: Hidden Classes
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.
> 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
More information about the valhalla-dev