On Tue, Jun 11, 2024 at 11:58 AM Ron Pressler <ron.press...@oracle.com> wrote:
> > > > 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. I thought that might be where Alan was headed with this. I would support this solution; it would solve the problem for conformant serialization libraries. If a class has a `readObject`/etc. then we use it - we wouldn't care if it was "natural" or generated. This also gives us the option to allow the user to use `opens` selectively to opt-in to special optimizations, without a major penalty if they do not. Is there already someone assigned for this task, or is it a hot-off-the-presses new idea? 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. > It would be great to see this. I've prototyped a few ideas for constructor-based deserialization in the past (essentially, using caller-sensitivity to control stream field access), but the issue always comes down to needing the entire class hierarchy to participate and play nicely, hence my suspicion that some amount of language/JDK changes would be needed. I would support any new work in this direction either way though; it gets rid of a lot of hackiness on the deserialization end. -- - DML • he/him
