Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21

[Johan Vos]

Hi Kevin, all,

I agree with this proposal and with the rationale behind it. It provides a
solid foundation for future consistent decisions as well.

- Johan

On Fri, Feb 16, 2024 at 11:14 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> All,
>
> Even though we build JavaFX binaries with JDK 21 as the boot JDK, the
> latest version of JavaFX still runs with JDK 17, although it isn't
> tested with older JDK versions. In order for JavaFX to be able to use
> newer JDK features, such as code snippets (in API docs), record
> patterns, pattern matching for switch statements, and so forth, 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.
>
> A question was raised [1] as to whether we should go even further and,
> once JDK 22 is released, jump straight to JDK 22 as a  minimum. While we
> could do that, I feel that there isn't sufficient justification for this
> at this time, although we could reconsider for next release.
>
> To this end, I propose to bump the minimum version of the JDK needed to
> run JavaFX 23 to JDK 21. I filed JDK-8321603 [2] to track this and
> prepared PR  #1370 [3] (I've moved the PR back to Draft, pending this
> discussion). This will not affect update releases of earlier versions of
> JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will continue to
> run with the same minimum JDK that they run on today.
>
> As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or
> later, although in practice, we don't bump the minimum required JDK
> version without a good reason. For example, while JavaFX 22 is built
> using JDK 21 as the boot JDK, it produces class files that will run with
> JDK 17, using "--release 17". The proposed change discussed here would
> update that in JavaFX 23 to "--release 21".
>
> 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.
>
> Comments are welcome.
>
> -- Kevin
>
> [1]
> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html
> [2] https://bugs.openjdk.org/browse/JDK-8321603
> [3] https://github.com/openjdk/jfx/pull/1370
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240221/76be8132/attachment.htm>