[nestmates] JDK-8235602: Re-examine if a hidden class should trust final non static fields

Mandy Chung mandy.chung at oracle.com
Thu Jan 30 18:25:15 UTC 2020



On 1/30/20 7:08 AM, Chris Hegarty wrote:
> This looks ok to me Mandy.

Thanks Chris.
> Hidden classes are, by definition, hostile to default serialization. I think that this is fine.
>
> Do you know of any motivation or use-cases for serialization of hidden classes? ( i.e. is it worth expending any effort giving consideration to a way to more easily support serialization/deserialization of hidden classes, without resorting to spinning your own custom mechanism, like say SerializedLambda )

It depends on the feature that uses hidden classes as its internal 
implementation details (e.g. serializable lambda).

Serializing a hidden class should serialize the properties present at 
the class generation time.  For example, serializing a lambda proxy 
records the information passed to the lambda factory site whereas 
serializing a dynamic proxy class records the list of proxy interfaces.

I think it may be possible to provide better 
serialization/deserialization support for hidden classes while it's not 
critical to expend the effort until there are more use cases showing it 
worth-wide doing it.

Mandy

> -Chris.
>
>> On 27 Jan 2020, at 21:08, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>> Deserialization is the primary use case for core reflection to allow writing to final fields after object construction.  Serializable hidden classes are required to use its own custom serialization mechanism.  With the properties of hidden classes, "non-discoverable" and "non-modifiable", I propose to make hidden classes final fields not-writeable via reflection and enables frameworks and language implementors to benefit from the final fields optimization with the use of hidden classes.   Core platform classes like lambdas will not have to pay for the price just because a few libraries (e.g. mocking) might want to write to final fields.
>>
>> java.lang.reflect.Field::set and Lookup::unreflectSetter already disallow the write-access to static final fields regardless of the accessible flag.  This proposes to disallow write-access to final non-static fields declared in a hidden class.
>>
>> There is no change to AccessibleObject::setAccessible that can be used to suppress language access control check.   Most frameworks use setAccessible to break encapsulation and access a member and they should not be impacted.
>>
>> I see that this spec change sets a precedence for JDK-8233873 [1] "final field values should be trusted constants", the general fix.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8235602/webrev.01/
>>
>> This patch also puts a stop in using sun.misc.Unsafe to find field offsets of hidden class.  jdk.internal.misc.Unsafe::objectFieldOffset is used by reflection machinery that I will follow up next.
>>
>> Mandy
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233873
>>



More information about the valhalla-dev mailing list