<div dir="ltr">I was advocated  to bump to JDK 22 last year, with FFM as a main reason to replace sun.misc.Unsafe [1], so of course I endorse this. The main rebuttal was that companies prefer to use LTS versions (although any distributor can declare any version as LTS), so I wonder if these considerations still take precedence or if FFM is too important to wait with.<div><br></div><div>- Nir</div><div><br></div><div>[1] <a href="https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html">https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2024 at 5:45 PM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" target="_blank">kevin.rushforth@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
<br>
Even though we build JavaFX 24 binaries with JDK 22 (and soon will build <br>
with JDK 23) as the boot JDK, the latest version of JavaFX still runs <br>
with JDK 21, although it isn't tested with older JDK versions. In order <br>
for JavaFX to be able to use newer JDK features, such as FFM (Panama), <br>
we need to increase the minimum version of the JDK that can run the <br>
latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX <br>
buildable and runnable on older versions of Java, and very little reason <br>
to continue to do so.<br>
<br>
To this end, I propose to bump the minimum version of the JDK needed to <br>
run JavaFX 24 to JDK 22. I filed JDK-8340003 [1] to track this and <br>
prepared Draft PR  #1588 [2]. This will *not* affect update releases of <br>
earlier versions of JavaFX (e.g., JavaFX 23.0.NN or JavaFX 21.0.NN), <br>
which will continue to run with the same minimum JDK that they run on today.<br>
<br>
The main driver for this is that we need to convert the memory <br>
management methods used by Marlin from sun.misc.Unsafe to something <br>
else, both for Java2D and JavaFX, and the natural choice is to use FFM <br>
(Panama), which is what will be done for Java2D. We want to do the same <br>
for JavaFX, which requires bumping the minimum to JDK 22. See <br>
JDK-8334137 [3].<br>
<br>
NOTE: this will not be an invitation to do wholesale refactoring of <br>
existing classes or methods to use newer language features (e.g., a PR <br>
that refactors existing switch statements and switch expressions into <br>
pattern-matching switch expressions would not be welcome). Rather, this <br>
can be seen as enabling judicious use of new features in new code, much <br>
as we did when we started allowing the use of "var", records, and <br>
pattern-matching instanceof.<br>
<br>
As a reminder, our stated position is that: A) we ensure that JavaFX N <br>
runs on JDK N-1 or later; and B) we encourage developers to use JDK N to <br>
run JavaFX N. It follows from this that if developers want to run their <br>
application on an LTS of the JDK, they should also get a corresponding <br>
LTS of JavaFX.<br>
<br>
Up until now we've been pretty conservative about bumping the minimum <br>
JDK version, and we've chosen an LTS version. However, this  has never <br>
been a hard requirement nor guarantee; whether or not the minimum <br>
happens to be an LTS should not be consideration. In the future, we <br>
could consider bumping the minimum version more automatically to, say, <br>
JDK N-2, which could be done fairly shortly after the fork for each new <br>
feature release. This proposal doesn't do that, but we could have a <br>
follow-on discussion as to whether to consider that.<br>
<br>
Comments are welcome.<br>
<br>
-- Kevin<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8340003" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8340003</a><br>
[2] <a href="https://github.com/openjdk/jfx/pull/1588" rel="noreferrer" target="_blank">https://github.com/openjdk/jfx/pull/1588</a><br>
[3] <a href="https://bugs.openjdk.org/browse/JDK-8334137" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8334137</a><br>
</blockquote></div>