<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
I just took the PR out of Draft, so it is ready for review.<br>
<br>
In case anyone is interested, I refer you to the recently-published
Informational JEP 14: The Tip & Tail Model of Library
Development [1], which outlines some of the thinking behind this.<br>
<br>
-- Kevin<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/14">https://openjdk.org/jeps/14</a><br>
<br>
<br>
<div class="moz-cite-prefix">On 10/2/2024 8:19 AM, Kevin Rushforth
wrote:<br>
</div>
<blockquote type="cite" cite="mid:e3f909c5-c5a1-4c21-8952-646fa19e87e0@oracle.com">
It's more an evolving realization that there is little benefit to
the OpenJFX community to force JavaFX to be tied to an LTS release
of the JDK, and a cost to doing so (both in additional testing,
opportunity cost of using new features, etc). LTS releases are
about stability and support; if an app developer wants to use the
latest features, they can grab JDK N and JavaFX N. If they want
stability, they can use an LTS of both. Brian Goetz and Georges
Saab have done a good job of advocating the benefits of this at
recent conferences.<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/2/2024 8:10 AM, Nir Lisker
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+0ynh8MJbSzwQCz1aGx_q3uk9pPF8Y-Y2=RxLSGfzLjqPi14w@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8340003</a><br>
[2] <a href="https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1588__;!!ACWV5N9M2RV99hQ!InHIRuBw3LOCE7wSivJoWkEgwW92mvZECzqG47D15a1E7kVIG_yZUW-QiFYu07mpldZ48t0V4nLv0aVwnS7v$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jfx/pull/1588</a><br>
[3] <a href="https://bugs.openjdk.org/browse/JDK-8334137" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8334137</a><br>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>