On Tue, Jun 11, 2024 at 12:57 PM Alan Bateman <alan.bate...@oracle.com> wrote:
> > > On 11/06/2024 18:19, David Lloyd wrote: > > : > > 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 > > > Not to my knowledge so you have cycles to prototype and have these methods > return a MH that work like a "default" readObject/writeObject then it would > help the discussion. > I think I can come up with *at least* a prototype in the next week or two. I have one concern though. The `readObject` method, when defined by users, must by specification do one of two things before it may read values from the stream: * Call `OIS.defaultReadObject()` * Call `OIS.readFields()` In the latter case, we don't have a problem, but if the user class calls `defaultReadObject` then we're back in the boat of having to reflectively set the fields of the class. We could possibly solve this by creating a *new* accessor which creates a parallel version of the method which *always* sets fields reflectively, even if a `readObject` already exists on the class. I'm not sure if there is a better solution. There is a similar problem on the write side, however this involves reading fields rather than writing them (obviously). -- - DML • he/him
