+1
I would like to put forth an opinion that we should NOT use non-comprehensive
switch expressions over enums, as they introduce a major incompatibility when
evolving that enum (i.e. when adding new values).
Consider this:
enum E { A, B }
E e;
switch(e) {
case A -> "a";
case B -> "b";
}
evolving to
enum A { A, B, C };
previously comprehensive switch expression explodes.
-andy
From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Kevin Rushforth
<kevin.rushfo...@oracle.com>
Date: Friday, February 16, 2024 at 14:12
To: openjfx-dev <openjfx-dev@openjdk.org>
Subject: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21
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
