> On 11 Jun 2024, at 17:27, David Lloyd <david.ll...@redhat.com> wrote: > > > > On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman <alan.bate...@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
