> On 11 Jun 2024, at 18:19, David Lloyd <david.ll...@redhat.com> wrote: > > 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.
Right. Excellent. > > Is there already someone assigned for this task, or is it a > hot-off-the-presses new idea? It’s a new idea. > 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. There’s no need to examine the class hierarchy. We can take this apart into two stages: Any class designed for serialization (and the axiom of “Serialization 2.0” is that only classes designed for serialization can be serialized) should offer a constructor that can recreate an object at an arbitrary (serializable) state, as well as access to whichever components make up that state. This should, ideally, be the situation today, but using this property today requires writing a custom serializer — code that knows how to access the components of the state of a particular class when serializing and knows how to pass them to an appropriate constructor when deserializing. What’s missing is a mechanism to automate this process. Some way to *generally* tell a class designed for serialization, “please give me the components of your state” when serializing, and a way to *generally* find an appropriate public constructor to which you can say, “here are your state components, now construct an object”. That is the broad idea outlined in Brian’s “Toward Better Serialization”[1] (if such a mechanism is ultimately introduced, the concrete details will likely be different). — Ron [1]: https://openjdk.org/projects/amber/design-notes/towards-better-serialization
