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

[Kevin Rushforth]

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