+1 On Sat, Feb 17, 2024, 15:37 John Hendrikx <john.hendr...@gmail.com> wrote:
> +1 > > On 16/02/2024 23:11, Kevin Rushforth 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 > > >
