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

[David Lloyd]

On Tue, Jun 11, 2024 at 12:57 PM Alan Bateman <Alan.Bateman at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/04c39684/attachment.htm>