[External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[Ron Pressler]

> On 11 Jun 2024, at 17:27, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 
> 
> On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 06/06/2024 18:37, David Lloyd wrote:
>> Just bumping this one more time. I intend to start by opening a JIRA to add the two proposed methods to `ReflectionFactory`, and go from there. I guess that we might need a JEP for the proposed serialization restrictions, which is going to be considerably more involved, so I'm putting that off as a second step for now, pending further discussion.
>> 
> 
> I don't think the JDK should be adding another backdoor for serialization libs to do deep reflection.
> 
> I'm curious, does your serialization library uses the ReflectionFactory to get method handles to the readObject/writeObject methods (if they are defined)?
> 
> Yes, all of the method-access methods on ReflectionFactory are used, not just for readObject/writeObject but also readObjectNoData, readResolve, and writeReplace, the constructor accessors, and the factory methods for OptionalDataException. We don't use the static initializer one though (maybe the ORB does, I'm not sure).
> 
> -- 
> - DML • he/him


Ok, good.

So the way the JDK’s built-in serialization mechanism allows custom implementation is by extending ObjectInputStream/ObjectOutputStream (and to that purpose it offers protected constructors of those two classes). ReflectionFactory offers access to non-public readObject/writeObject methods, but it does not currently offer a way to exploit the default field-based reflection when such methods are not explicitly declared.

Given that, I think that an appropriate mechanism to consider is having ReflectionFactory offer access to MethodHandles that can perform de/serialization using the default JDK field-based serialization, but still requiring the serialization library to extend ObjectInputStream/ObjectOutputStream — i.e. those MethodHandles will invoke the appropriate OIS/OOS methods for writing fields — but not offering any direct access to non-public fields. This would still be an interim mechanism, and it may still require significant work by serialization libraries that don’t wish to offer custom serializers for JDK classes and don’t wish to use --add-opens. 

Looking further ahead, a future JDK mechanism to support custom serialization would still be based on invoking public constructors. I.e., the same effect could be achieved today — albeit with some more work — by the serialization library offering custom serializers for JDK classes that invoke their public constructors (the difference being that such a future mechanism would make it easier to automatically identify the public constructor to be invoked, whereas today it would need to be individually determined on a per-class basis). Serialization libraries that want to be better prepared for that future and not do further significant work when it arrives, should use custom serializers for JDK classes that invoke public constructors rather than rely on the mechanism I proposed above or on --add-opens.

Whatever they choose to do, to assist in forming some future JDK mechanism that could support custom serialization, serialization libraries should report which JDK classes they commonly serialize and what public constructors they are missing, if any.

— Ron