So I think we should official define the JDK N-1 and JDK N but don't pro
actively break JDK N-2, ... if there's no real value.
Perhaps your suggestion is a good compromise: if we choose this
approach, then we would still claim support for only JDK N-1 and JDK N,
but wouldn't go out of our way to stop it from running on JDK N-2
unless/until there was a feature or bug fix that required something from
JDK N-1. Given that it could break -- either because we need something
from JDK N-2 or because of a bug that gets introduced and we no longer
test with JDK N-2 -- application vendors wouldn't be able to rely on FX
N working with JDK N-2.
Johan: what do you think?
-- Kevin
On 9/24/2018 12:14 PM, Tom Schindl wrote:
Hi,
As a general rule I'm fine with that but as outlined in another reply we
should only break building with older JDKs in case it really adds value.
So I think we should official define the JDK N-1 and JDK N but don't pro
actively break JDK N-2, ... if there's no real value.
Tom
On 24.09.18 16:40, Kevin Rushforth wrote:
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.
This is also my preference.
-- Kevin
On 9/24/2018 12: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.
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.
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
