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

Chris Hegarty chris.hegarty at oracle.com
Thu Jan 30 15:08:48 UTC 2020


This looks ok to me Mandy.

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 )

-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