[External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[David Lloyd]

On Thu, Jun 13, 2024 at 8:39 AM Alan Bateman <Alan.Bateman at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/2c085aa2/attachment.htm>