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

[Ron Pressler]

> 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).

— Ron