Draft JEP: Deprecate Memory-Access Methods in sun.misc.Unsafe for Removal

[Attila Kelemen]

It is kind of a long due change, but one thing that could improve the user
experience by a lot, if there was an officially (or semi-officially)
recognized library that works on all JVM (well, maybe 8+ only). It could be
a multi-release jar, or (possibly in addition to that) a multi-variant
dependency [1] (though the latter would only work from Gradle, but would
produce smaller dependencies).

The above would be greatly beneficial, because then likely we will have
issues with libraries supporting older versions of the JDK. That is, I
don't expect everyone to mess with creating their own multi JDK support
variants, and not doing so will cause pain and suffering downstream (at
least my experience is that many library developers won't go to great
lengths to support multiple JDK versions, and would rather push things to
the farthest date possible). However, if such a well-known library existed,
then I would expect that many would see it as "worth the effort" to move to
it a lot sooner.

It should be (semi-)officially recognized, because then that would be more
reassuring knowing that JIT developers know, and test that there is not
much performance issue with using this particular library.


[1] https://docs.gradle.org/current/userguide/feature_variants.html

Attila

Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2024. jan. 16.,
K, 19:01):

> Hi.
>
> With the FFM API [1] made permanent in JDK 22 (along with VarHandle in JDK
> 9 [2]),
> the vast majority of methods in sun.misc.Unsafe — those used for memory
> access
> operations — now have standard, supported replacements. Therefore, it is
> time
> to begin the process of deprecating and removing those methods from
> sun.misc.Unsafe. [3][4]
>
> When methods in sun.misc.Unsafe were deprecated and removed in the past
> after
> standard replacements were introduced, there was little impact on the Java
> ecosystem.
> However, the memory-access methods are much better known, and we expect
> that
> removing such a large number of methods (79) will impact libraries.
> Accordingly,
> we are proposing the deprecation and removal via a JEP, for maximum
> visibility.
> Furthermore, the removal process we propose is more gradual than the one
> used for
> other sun.misc.Unsafe methods and follows a process similar to ones we
> followed for
> some standard APIs: the compile-time warnings for the use of deprecated
> methods are
> to be followed in later releases by runtime warnings, which are then to be
> followed by
> errors. A new command-line option will help developers diagnose their
> reliance on the
> memory-access methods of sun.misc.Unsafe and plan to migrate away from it.
>
> The proposed process is described in this draft JEP [5]. Comments are
> welcome.
>
> The draft JEP does not propose to remove the sun.misc.Unsafe class itself.
> Indeed, a small number of its methods are unaffected by this propsal; their
> individual fates will be determined separately.
>
> — Ron
>
> [1]: https://openjdk.org/jeps/454
> [2]: https://openjdk.org/jeps/193
> [3]: https://youtu.be/4HG0YQVy8UM
> [4]:
> https://cr.openjdk.org/~psandoz/conferences/2015-JavaOne/j1-2015-unsafe-CON7076.pdf
> [5]: https://openjdk.org/jeps/8323072
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20240117/7963c3fb/attachment.htm>