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

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jdk-dev" <jdk-dev at openjdk.org>
> Sent: Tuesday, May 7, 2024 1:01:00 PM
> Subject: Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

>> On 6 May 2024, at 17:47, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hello,
>> I think this JEP is a little too optimistic,
> 
> Hi.
> See Maurizio’s comment regarding the magnitude of impact on performance, but
> more generally, we’re transitioning from a world where there was no good way to
> accomplish these things in a supported manner at all (or with an even higher
> performance cost) but there was a way to accomplish them in an unsupported and
> unsafe manner, to a world where there is a way to accomplish these things in a
> supported and usually safe manner (and/or with better performance compared to
> the old supported way) and there is still a way to do these things in an
> unsupported and unsafe manner. I.e. the new world clearly dominates the old and
> no ability is being taken away.
> 
> The cases where it is justifiable to do something unsafe *and* unsupported are
> relatively rare, and the fact that they require switching from one unsupported
> class to another is not a risk, and we usually avoid documenting unsupported
> mechanisms. When developers opt to use an unsupported mechanism — even if for
> justifiable reasons — they implicitly accept that they will occasionally need
> to change their code to respond to internal JDK changes.
> 
> Even though sun.misc.Unsafe has never been supported or documented, it’s become
> popular because there was no good replacement even for usages that could have
> been made safe — hence the JEP and CSR that acknowledge that fact and respond
> to it with a gradual process.
> 
> That there may still be cases where developers may choose to use an unsupported
> mechanism is always true, but not something we explicitly acknowledge, as we
> don’t recommend that.
> 
> Having said all that, we will continue to try and improve the performance of
> supported APIs, be they safe or unsafe (restricted).


I fully agree, my point is just that it will take time to move from Unsafe to the foreign API, hence the too optimistic.

> 
> — Ron

regards,
Rémi