Proposal: Bump minimum JDK for JavaFX 24 to JDK 22

[Nir Lisker]

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.rushforth at 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
> [3] https://bugs.openjdk.org/browse/JDK-8334137
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241002/fc135579/attachment.htm>