On Thu, Jun 13, 2024 at 8:39 AM Alan Bateman <alan.bate...@oracle.com> wrote:
> On 12/06/2024 15:23, David Lloyd wrote: > > > : > . > > I have a *very* rough prototype up [1]. It adds two new accessor methods > to `ReflectionFactory`: `defaultReadObjectForSerialization` and > `defaultWriteObjectForSerialization`. It was easier than expected, due > largely to the classfile API, which is really nice. > > These methods create an artificial `readObject`/`writeObject` method in a > hidden+nestmate class connected to the original class, which uses the > stream's `GetField`/`PutField` to access the stream data and normal field > operations to access the class fields. For usage, these methods can be used > when `read|writeObjectForSerialization` return `null`, *or* when > `defaultRead|WriteObject` is used. > > Good to hear you've got a prototype to discuss. I don't think I can look > at what you have in your own repo but I do have a question. Do the > defaultXXX methods return a method handle or do they fail/null when there > are read/writeObject methods? Asking if they will bypass these methods. > They will still return a method handle in this case. The method handle doesn't *bypass* the provided methods - per se - for example if the fields in question are `transient` then these methods would not access them. But, I could not think of any other way to deal with the `defaultReadObject`/`defaultWriteObject` situation than to allow serialization libraries to do this (where the OIS/OOS implementation is being asked by the serialized class to read or write the field values from/to the serialization stream). Maybe you have another idea? -- - DML • he/him
