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

[Kevin Rushforth]

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