[nestmates] JDK-8235602: Re-examine if a hidden class should trust final non static fields
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.
> 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.
>> 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  "final field values should be trusted constants", the general fix.
>> 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.
>>  https://bugs.openjdk.java.net/browse/JDK-8233873
More information about the valhalla-dev