[12] RFR: JDK-8209966: Update minimum boot JDK to 11

Discussion:

Kevin Rushforth

2018-09-21 22:27:28 UTC

Please review the following on GitHub:

https://bugs.openjdk.java.net/browse/JDK-8209966
https://github.com/javafxports/openjdk-jfx/pull/174

This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11.

-- Kevin

Ty Young

2018-09-22 01:00:17 UTC

Permalink

Post by Kevin Rushforth
https://bugs.openjdk.java.net/browse/JDK-8209966
https://github.com/javafxports/openjdk-jfx/pull/174
This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11.
-- Kevin

Is requiring the previously released JDK to build JavaFX really
necessary? Does something *actually* break as a result of using an older
boot JDK?

If not, this is just going to make compiling JavaFX a real pain as you
need to compile(or somehow find) a JDK that is one version behind, and
if you don't have it then you need to compile the JDK with JavaFX before
that(and repeat).

In other words, if I wanted to compile JavaFX 12 right now I'd need to
use Oracle JDK 10(which may not even be available for download in the
future, who knows?), use it to compile JDK 11 with JavaFX 11, and then
use that to compile JavaFX 12 if I couldn't find JDK 11 with JavaFX
online somewhere.

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.

Thanks.

Kevin Rushforth

2018-09-22 13:50:53 UTC

Permalink

Post by Ty Young
Is requiring the previously released JDK to build JavaFX really
necessary? Does something *actually* break as a result of using an
older boot JDK?

Yes, there is a good reason to do this, and that is to fix JDK-8210092
[1], which gets rid of the legacy swing interop implementation and the
associated qualified exports, and some crufty build logic to optionally
exclude the classes that depend on JDK 11; this also fixes JDK-8210759
[2] . Also, JDK 10 is obsoleted by JDK 11, which is an LTS, so even if
we don't adopt a model of always bumping the minimum boot JDK for each
release, it is appropriate to do so now.

Post by Ty Young
In other words, if I wanted to compile JavaFX 12 right now I'd need to
use Oracle JDK 10(which may not even be available for download in the
future, who knows?), use it to compile JDK 11 with JavaFX 11, and then
use that to compile JavaFX 12 if I couldn't find JDK 11 with JavaFX
online somewhere.

You misunderstand. Today you need to use a JDK 10 (or JDK 11) *without*
the JavaFX classes to build JavaFX 12, just like we did for building
JavaFX 11. Starting with JDK 11 there are no more JDKs that include
JavaFX. That's why we build JavaFX as a separate SDK and set of maven
modules.

Post by Ty Young
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.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8210092
[2] https://bugs.openjdk.java.net/browse/JDK-8210759

Johan Vos

2018-09-24 07:12:05 UTC

Permalink

Post by Kevin Rushforth

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.
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

Kevin Rushforth

2018-09-24 14:40:50 UTC

Permalink

Post by Johan Vos
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

Post by Johan Vos

Post by Ty Young
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

Post by Ty Young
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.
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

Tom Schindl

2018-09-24 19:14:22 UTC

Permalink

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

Post by Kevin Rushforth

This is also my preference.
-- Kevin

Post by Johan Vos
    > 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.
    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

--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Kevin Rushforth

2018-09-26 15:22:57 UTC

Permalink

Post by Tom Schindl
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

Post by Tom Schindl
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

Post by Kevin Rushforth

This is also my preference.
-- Kevin

Johan Vos

2018-09-26 19:45:11 UTC

Permalink

I agree with the idea of not actively breaking things if not needed, on the
other hand I like predictability (instead of remembering that JavaFX 19
works with Java 17 but JavaFX 20 doens't work with Java 18 etc).
But from a pragmatic point, I'm ok with it.

The main difficulty in the whole minimum boot JDK is probably the classfile
format. If we now compile with JDK 11 and produce bytecode with version 55,
it won't run on JDK 10 VM's, even though there might be no API's or VM
specs that are specific to 11.
I agree that if there is no reason to make use of new API's or VM
functionality, there is no reason to make it not work on previous JDK's.

- Johan

Post by Kevin Rushforth

Post by Tom Schindl
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.

Post by Kevin Rushforth

This is also my preference.
-- Kevin

Post by Johan Vos

Post by Ty Young
And it's only going to get worse as time goes on. Would it not

Post by Tom Schindl

Post by Kevin Rushforth

Post by Johan Vos

Post by Ty Young
possible to support up until the last JDK LTS(Starting at 11)

release

Post by Ty Young
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

Post by Tom Schindl

Post by Kevin Rushforth

Post by Johan Vos
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.
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

Post by Tom Schindl

Post by Kevin Rushforth

Post by Johan Vos
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

Ty Young

2018-09-26 06:27:31 UTC

Permalink

Post by Ty Young

Post by Ty Young
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

Post by Ty Young
for building JavaFX? I feel like maybe that would be more

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.

Post by Ty Young
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.

Post by Ty Young
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

José J. Rodriguez

2018-09-26 21:26:41 UTC

Permalink

FWIW, I would prefer it if jfx only followed the LTS jdk releases.

Regards,
Joe1962

Nir Lisker

2018-09-27 00:38:29 UTC

Permalink

Post by Kevin Rushforth
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.

I would be surprised if there will be a release without a language change,
as I don't recall any release without one, and Amber (and friends) keeps
providing.
Now, we can discuss what is "required". Java 11 added 'var' for Lambdas. Is
it something worth bumping the minimum version for? Isn't it enough that
it's used once in the codebase to make it incompatible with pre-11 JDK's?
And if so, we'll have to document what contributors are allowed to use and
what not when working on JavaFX.

We will have to have this discussion every release to determine if we bump
the minimum version or not.

On Thu, Sep 27, 2018 at 12:27 AM José J. Rodriguez <

Post by Kevin Rushforth

FWIW, I would prefer it if jfx only followed the LTS jdk releases.
Regards,
Joe1962

Johan Vos

2018-09-27 06:52:04 UTC

Permalink

Historically, there was a no-go for default interface methods in the 8-tree
a long time ago, as those would break the android port (thanks Stephen
Northover for imposing that).
Hence, I was happy with the restrictions not to use new language features.
Android is a special case though, as that is the only environment I know
about where the JavaFX applications (and jars) are not running on
controllable JRE's. If JavaFX applications are packaged and bundled with
JRE's, I don't see reasons why moving to new JDK versions can be a problem.

However, if there are more cases like Android, where the developer doesn't
control the version at runtime, we have to consider being more conservative.

- Johan

Post by Nir Lisker

Post by Kevin Rushforth
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.

I would be surprised if there will be a release without a language change,
as I don't recall any release without one, and Amber (and friends) keeps
providing.
Now, we can discuss what is "required". Java 11 added 'var' for Lambdas. Is
it something worth bumping the minimum version for? Isn't it enough that
it's used once in the codebase to make it incompatible with pre-11 JDK's?
And if so, we'll have to document what contributors are allowed to use and
what not when working on JavaFX.
We will have to have this discussion every release to determine if we bump
the minimum version or not.
On Thu, Sep 27, 2018 at 12:27 AM José J. Rodriguez <

Post by Kevin Rushforth

FWIW, I would prefer it if jfx only followed the LTS jdk releases.
Regards,
Joe1962