On 9/24/18 2:12 AM, Johan Vos wrote:
> And it's only going to get worse as time goes on. Would it not be
> possible to support up until the last JDK LTS(Starting at 11)
release
> for building JavaFX? I feel like maybe that would be more
reasonable.
This is a good question, and maybe in the future we might not be so
quick to do this...or maybe we will. We should discuss this
before we
get to this point for JavaFX 13, a little less than six months
from now.
The choices for the model are:
1. Allow building JavaFX N with either JDK N-1 or JDK N.
2. Allow building JavaFX N with the most recent LTS or later.
Choice #1 will allow JavaFX to better keep pace with JDK features
(API
or language features). Choice #2 will allow JavaFX to build and
run with
the most current, stable JDK LTS at the cost of not being able to use
newer JDK features.
One of the reasons Java is moving to a fast release cadence is because
today, this is required to stay relevant in a fast-changing landscape.
I think we need to do the same with JavaFX. We should be able to
leverage the latest and greatest advances in the JDK, since this will
allow JavaFX to move fast as well, which is required to stay relevant.
Maybe it's because I don't work for a large corporation, but I don't see
this supposed "fast-changing" landscape. To me, it just looks like Java
is trying to appeal to all the people from Python/C++/other languages
who can't or have a hard time writing object oriented code by
introducing a more lazy "functional" and "concise" way of programming.
The amount of actual meaningful updates to the language in 10 and 11 in
my eyes is fairly small, which is somewhat expected with the faster
release cycles. If there was actually a "fast-changing" landscape, I
would think that there would more meaningful and useful updates rather
than the 50/50 "functional and/or concise"/other misc updates that has
been the case for JDK 10 and 11.
Personally, whatever was updated that resulted in Netbeans properly
using the OS's Look and Feel was the only worthwhile update of the
entire JDK 11 release IMO, but I digress.
To be clear, I'm not that concerned about breaking compatibility with
older versions of the JDK because of API updates/introductions/removals
or new, better tools being introduced. I'm more concerned about
backwards compatibility being broken for stupid reasons like new lazy
language updates that have no actual value or can be done with older
compatible ways just because people want to be lazy, "functional", and
"concise" which has become a bit of a hot trend lately.
If you want to run on the latest stable JDK LTS, the logical
consequence seems to me you use the latest stable JavaFX LTS. There is
LTS support available for both Java and JavaFX 11 and they are pretty
well aligned.
That's all fine and dandy except for the fact that you can't guarantee
what JRE is being run if you haven't moved to Java 9 modules. What do
you do, wait a few months after a new LTS is out and then update your
application with new JDK/JavaFX features and say "tough luck" to anyone
who is still using a previous LTS? What if a user has a newer JRE
installed with a feature that exists on the previous LTS removed but not
their newer JRE that JavaFX LTS depends on?
I've never tried it, but I guess you could prompt the user to download a
compatible JRE via a Swing GUI and use that to launch the application
via a launcher... but that's just awful for so many different reasons.
Having said that, there is no point in moving forward just for the fun
of it. We also have to distinguish between changes in the VM or in the
core Java API's.
My opinion is that if a new feature is added to JDK N, we can really
take advantage of it in JavaFX (N+1).
In some cases, there won't be new features relevant to OpenJFX. But
even then, I don't think we can't change our rules on a per-release
case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12;
but JavaFX 15 works with Java 14 and Java 15 and not with Java 13).
In general, I think developers updating from JavaFX 11-12-13 are also
capable of updating the JDK from 11-12-13, so I prefer the coupling
1. Allow building JavaFX N with either JDK N-1 or JDK N.
- Johan
