RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory [v9]

Chen Liang liach at openjdk.org
Wed Nov 13 17:51:28 UTC 2024


On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>  - More tests
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 80:

> 78:     private ReflectionFactory() {
> 79:         this.langReflectAccess = SharedSecrets.getJavaLangReflectAccess();
> 80:         this.javaObjectStreamReflectionAccess = SharedSecrets.getJavaObjectStreamReflectionAccess();

ReflectionFactory is created on very early bootstrap, even before `JavaLangAccess` is ready.  This extra dependency is only used when the unsupported version is used, and this dependency, calling MethodHandle, should have changed the boot class loading/initialization sequence by making MH initialization early.  Can you check with a hello world app and run it with `-Xlog:class+init` to check the initialization sequence?

I strongly recommend not caching this access object, and just call `getJavaObjectStreamReflectionAccess()` on demand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840918169


More information about the core-libs-dev mailing list