I'm split on this myself :)
As JavaFX is more of a library now, and not part of the JDK, allowing
broader compatibility could be beneficial: people can get new JavaFX
features without having to upgrade the JDK (each time) as well. For me
personally, that is moot since I tend to just track the latest JDK
release that has features I want, but this might not be the case for
other (corporate?) JavaFX users. Some small inconveniences in the JavaFX
code base to appeal to a broader audience could be good.
From a developer perspective, the new features are compelling, records
and cast-free instanceof will be nice, but it is not the end of the
world to live without them for a bit longer.
For something like JavaFX, a middle ground might be good, where it
tracks the latest LTS (11, 17, 21, etc...)
My 2 cents,
--John
On 19/07/2022 15:44, Kevin Rushforth wrote:
Even though we build JavaFX binaries with JDK 18 as the boot JDK, the
latest version of JavaFX still runs with JDK 11 (and is capable of
being built using JDK 12 or later, and with some limitations, using
JDK 11), although it isn't tested with older JDK versions. In order
for JavaFX to be able to use newer JDK features, such as records,
switch expressions, text blocks, 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.
To this end, I propose to bump the minimum version of the JDK needed
to run JavaFX 20 to JDK 17. I filed JDK-8290530 [1] to track this.
This will not affect update releases of earlier versions of JavaFX
(e.g., 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 haven't bumped the minimum required
JDK version in several releases. So, while JavaFX 19 is built using
JDK 18 as the boot JDK, it produces class files that will run with JDK
11, using "--source 11 --target 11". The proposed change discussed
here would update that in JavaFX 20 to "--source 17 --target 17".
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 turns a bunch of existing data classes into records 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".
Absent a compelling reason to remain stuck in the past, I plan to send
out a pull request for this change next week.
Comments are welcome.
-- Kevin
[1] https://bugs.openjdk.org/browse/JDK-8290530
