I just took the PR out of Draft, so it is ready for review.
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.
-- Kevin
[1] https://openjdk.org/jeps/14
On 10/2/2024 8:19 AM, Kevin Rushforth wrote:
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.
-- Kevin
On 10/2/2024 8:10 AM, Nir Lisker wrote:
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.
- Nir
[1]
https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html
On Wed, Oct 2, 2024 at 5:45 PM Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
All,
Even though we build JavaFX 24 binaries with JDK 22 (and soon
will build
with JDK 23) as the boot JDK, the latest version of JavaFX still
runs
with JDK 21, although it isn't tested with older JDK versions. In
order
for JavaFX to be able to use newer JDK features, such as FFM
(Panama),
we need to increase the minimum version of the JDK that can run the
latest JavaFX. Additionally, there is an ongoing cost to keeping
JavaFX
buildable and runnable on older versions of Java, and very little
reason
to continue to do so.
To this end, I propose to bump the minimum version of the JDK
needed to
run JavaFX 24 to JDK 22. I filed JDK-8340003 [1] to track this and
prepared Draft PR #1588 [2]. This will *not* affect update
releases of
earlier versions of JavaFX (e.g., JavaFX 23.0.NN or JavaFX 21.0.NN),
which will continue to run with the same minimum JDK that they
run on today.
The main driver for this is that we need to convert the memory
management methods used by Marlin from sun.misc.Unsafe to something
else, both for Java2D and JavaFX, and the natural choice is to
use FFM
(Panama), which is what will be done for Java2D. We want to do
the same
for JavaFX, which requires bumping the minimum to JDK 22. See
JDK-8334137 [3].
NOTE: this will not be an invitation to do wholesale refactoring of
existing classes or methods to use newer language features (e.g.,
a PR
that refactors existing switch statements and switch expressions
into
pattern-matching switch expressions would not be welcome).
Rather, this
can be seen as enabling judicious use of new features in new
code, much
as we did when we started allowing the use of "var", records, and
pattern-matching instanceof.
As a reminder, our stated position is that: A) we ensure that
JavaFX N
runs on JDK N-1 or later; and B) we encourage developers to use
JDK N to
run JavaFX N. It follows from this that if developers want to run
their
application on an LTS of the JDK, they should also get a
corresponding
LTS of JavaFX.
Up until now we've been pretty conservative about bumping the
minimum
JDK version, and we've chosen an LTS version. However, this has
never
been a hard requirement nor guarantee; whether or not the minimum
happens to be an LTS should not be consideration. In the future, we
could consider bumping the minimum version more automatically to,
say,
JDK N-2, which could be done fairly shortly after the fork for
each new
feature release. This proposal doesn't do that, but we could have a
follow-on discussion as to whether to consider that.
Comments are welcome.
-- Kevin
[1] https://bugs.openjdk.org/browse/JDK-8340003
[2] https://github.com/openjdk/jfx/pull/1588
<https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1588__;!!ACWV5N9M2RV99hQ!InHIRuBw3LOCE7wSivJoWkEgwW92mvZECzqG47D15a1E7kVIG_yZUW-QiFYu07mpldZ48t0V4nLv0aVwnS7v$>
[3] https://bugs.openjdk.org/browse/JDK-8334137
