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

[Ron Pressler]

> On 7 May 2024, at 13:02, forax at univ-mlv.fr wrote:
> 
> And now the controvertial part, if I control the command line, now i've a tradeoff, I can write my own malloc library as you suggest or I can export jdk.internal.misc to access jdk.internal.misc.Unsafe. The latter means using an unsupported API which is bad but it's a drop-in replacement for sun.misc.Unsafe, which is tempting. 

There are two aspects here: who is the one making the decision and what information is communicated.

No one can place any restriction on the application owner (and no one should). The control the executable, and just as they can set any command line option they like, they can also use a modified JDK or write their program in C. They are in control, they have full power, and we have no desire to restrict them in any way. What we do want is to provide them with the right information — i.e. allow them to make informed decisions — which is why we place restrictions only on libraries: they must communicate to the application author what risks they require.

Then there’s the matter of what risks are taken and how they’re communicated. Using a restricted but supported API with --enable-native-access means that the application owner takes the risk of undefined behaviour. But if a library uses internal JDK classes then it must ask the application for a very different command line, one that includes add-opens/exports. This different command line communicates two additional risks to maintenance and performance taken on top of the undefined behaviour risk. When a library requires the application to open/export java.base it asks it to acknowledge the risk that the library may not keep up with internal changes to the JDK (e.g. an internal class may change in an incompatible way and without notice to accommodate value types, which would require an immediate change in the library) or that the JDK may need to disable certain optimisations due to that library (e.g. we’re about to introduce another restriction on mutating finals to allow better compiler optimisations; we may have to disable those optimisations for modules that open java.base).

So an application author can always do what they wish, but a library must communicate to the application author the *different* classes of risk it would be exposed to if it choose to use a restricted but supported API or an internal, unsupported mechanism.

— Ron