<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2024 at 11:58 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 11 Jun 2024, at 17:27, David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>> wrote:<br>
> On 06/06/2024 18:37, David Lloyd wrote:<br>
>> 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.<br>
>> <br>
> <br>
> I don't think the JDK should be adding another backdoor for serialization libs to do deep reflection.<br>
> <br>
> I'm curious, does your serialization library uses the ReflectionFactory to get method handles to the readObject/writeObject methods (if they are defined)?<br>
> <br>
> 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).<br>
> <br>
> -- <br>
> - DML • he/him<br>
<br>
<br>
Ok, good.<br>
<br>
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.<br>
<br>
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.</blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Is there already someone assigned for this task, or is it a hot-off-the-presses new idea?<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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. <span style="font-family:Arial,Helvetica,sans-serif">I would support any new work in this direction either way though; it gets rid of a lot of hackiness on the deserialization end.</span></div></div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>