[External] : Re: Proposal: Bump minimum JDK for JavaFX 24 to JDK 22

Tue Oct 8 17:54:45 UTC 2024

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.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
>>     <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1588__;!!ACWV5N9M2RV99hQ!InHIRuBw3LOCE7wSivJoWkEgwW92mvZECzqG47D15a1E7kVIG_yZUW-QiFYu07mpldZ48t0V4nLv0aVwnS7v$>
>>     [3] https://bugs.openjdk.org/browse/JDK-8334137
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241008/45e93cc2/attachment-0001.htm>