I've been thinking about this for a few weeks and agree with the general consensus.
For me personally, it will make things more tricky as big customers (that usually have their own IT department) stick to 'LTS' versions and there is not too much you can do against that (I tried).
Sometimes there are also tools or other things that block a possible migration.
That being said, I fully understand the need to upgrade and that we need to prepare JFX for the JDK changes because there is work to be done.
I think it's quite unreasonable to wait just because some companies don't understand the LTS concept at all or are unwilling to do so.
Even if it makes my life more difficult for some projects.
So a +1 from me.
-- Marius
Gesendet: Mittwoch, 02. Oktober 2024 um 16:45 Uhr
Von: "Kevin Rushforth" <kevin.rushfo...@oracle.com>
An: "openjfx-dev" <openjfx-dev@openjdk.org>
Betreff: Proposal: Bump minimum JDK for JavaFX 24 to JDK 22
Von: "Kevin Rushforth" <kevin.rushfo...@oracle.com>
An: "openjfx-dev" <openjfx-dev@openjdk.org>
Betreff: Proposal: Bump minimum JDK for JavaFX 24 to JDK 22
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
[3] https://bugs.openjdk.org/browse/JDK-8334137
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
[3] https://bugs.openjdk.org/browse/JDK-8334137
