<div dir="ltr">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).<div><br></div><div>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.</div><div><br></div><div>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.<br><div><br></div><div><div><br></div><div>[1] <a href="https://docs.gradle.org/current/userguide/feature_variants.html" target="_blank">https://docs.gradle.org/current/userguide/feature_variants.html</a></div></div></div><div><br></div><div>Attila</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> ezt írta (időpont: 2024. jan. 16., K, 19:01):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi.<br>
<br>
With the FFM API [1] made permanent in JDK 22 (along with VarHandle in JDK 9 [2]), <br>
the vast majority of methods in sun.misc.Unsafe — those used for memory access <br>
operations — now have standard, supported replacements. Therefore, it is time <br>
to begin the process of deprecating and removing those methods from sun.misc.Unsafe. [3][4]<br>
<br>
When methods in sun.misc.Unsafe were deprecated and removed in the past after <br>
standard replacements were introduced, there was little impact on the Java ecosystem. <br>
However, the memory-access methods are much better known, and we expect that <br>
removing such a large number of methods (79) will impact libraries. Accordingly, <br>
we are proposing the deprecation and removal via a JEP, for maximum visibility. <br>
Furthermore, the removal process we propose is more gradual than the one used for <br>
other sun.misc.Unsafe methods and follows a process similar to ones we followed for <br>
some standard APIs: the compile-time warnings for the use of deprecated methods are <br>
to be followed in later releases by runtime warnings, which are then to be followed by <br>
errors. A new command-line option will help developers diagnose their reliance on the <br>
memory-access methods of sun.misc.Unsafe and plan to migrate away from it.<br>
<br>
The proposed process is described in this draft JEP [5]. Comments are welcome.<br>
<br>
The draft JEP does not propose to remove the sun.misc.Unsafe class itself.<br>
Indeed, a small number of its methods are unaffected by this propsal; their<br>
individual fates will be determined separately.<br>
<br>
— Ron<br>
<br>
[1]: <a href="https://openjdk.org/jeps/454" rel="noreferrer" target="_blank">https://openjdk.org/jeps/454</a><br>
[2]: <a href="https://openjdk.org/jeps/193" rel="noreferrer" target="_blank">https://openjdk.org/jeps/193</a><br>
[3]: <a href="https://youtu.be/4HG0YQVy8UM" rel="noreferrer" target="_blank">https://youtu.be/4HG0YQVy8UM</a><br>
[4]: <a href="https://cr.openjdk.org/~psandoz/conferences/2015-JavaOne/j1-2015-unsafe-CON7076.pdf" rel="noreferrer" target="_blank">https://cr.openjdk.org/~psandoz/conferences/2015-JavaOne/j1-2015-unsafe-CON7076.pdf</a><br>
[5]: <a href="https://openjdk.org/jeps/8323072" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8323072</a><br>
<br>
<br>
</blockquote></div>