Proposal: Bump minimum JDK version for JavaFX 20 to JDK 17

[Kevin Rushforth]

I agree that we should separate the question of what to do today from 
what our policy should be for future updates. As has been mentioned by 
several folks, JDK 17 today is the obvious choice.

Btw, a couple people pointed out to me that we should really use 
'--release 17' instead of '--source 17 --target 17'. Since gradle now 
supports that directly, that's what we'll do instead. This will prevent 
accidental use of APIs from the current boot JDK (we've kind of gotten 
lucky that we haven't hit this with as old as JDK 11 now is).

We should continue the discussion of what our policy should be going 
forward. It seems like most developers are favoring bumping the minimum 
to an LTS when we do bump it. That has a definite appeal, and with a 2 
year LTS cycle, doesn't seem too long to wait for new features. We could 
revisit this if there is a compelling enough feature in, say, JDK 22, 
but absent something so compelling that we would want to jump early, 
sticking with an LTS makes sense.

As a data point, the earliest we could bump to requiring JDK 21 as a 
minimum is in JavaFX 22 (so one year after the bump to JDK 17), although 
I'm not arguing that we should. The reason for this is that as an 
unbundled release, we can't realistically require the in-progress JDK NN 
early access as the minimum needed to build and run JavaFX NN early 
access. It was hard enough when we were bundled to use new features 
under development, but completely infeasible otherwise.

The interesting question, then is: what should be the driver for the 
next time we bump the minimum JDK? We have at least a year to figure out 
when the next time should be.

-- Kevin


On 7/19/2022 1:38 PM, Philip Race wrote:
> I've read the various comments so far and so have weighed those and my 
> view is that
> it is about time to move on from JDK11 and think a policy of making 
> the minimum an LTS is a
> reasonable position - so JDK 17 LTS is what comes out of that today.
>
> What to do in future (ie what is the policy) is a separate question
>
> OpenJDK LTS releases will be every two years in future, so there is a 
> reasonable argument that
> is too frequent to bump the FX minimum without a really compelling 
> reason.
>
> Also consider that FX 20 will GA 4 1/2 years after FX 11  and the next 
> JDK LTS will be 21 ..
> just 6 months later .. we surely aren't going to bump the minimum 
> again immediately.
>
> So we should not have a policy of the "latest LTS" should always be 
> the minimum - just that it should
> be "some" LTS
>
> And perhaps we skip every other LTS or at the very least we don't bump 
> until the LTS has been available for 1 year ..
>
> -phil.
>
> PS I agree this should never be an invitation for code churn with no 
> conceivable benefit to the users of the platform.
>
>
> On 7/19/22 6:44 AM, Kevin Rushforth wrote:
>> Even though we build JavaFX binaries with JDK 18 as the boot JDK, the 
>> latest version of JavaFX still runs with JDK 11 (and is capable of 
>> being built using JDK 12 or later, and with some limitations, using 
>> JDK 11), although it isn't tested with older JDK versions. In order 
>> for JavaFX to be able to use newer JDK features, such as records, 
>> switch expressions, text blocks, 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.
>>
>> To this end, I propose to bump the minimum version of the JDK needed 
>> to run JavaFX 20 to JDK 17. I filed JDK-8290530 [1] to track this. 
>> This will not affect update releases of earlier versions of JavaFX 
>> (e.g., 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 haven't bumped the minimum 
>> required JDK version in several releases. So, while JavaFX 19 is 
>> built using JDK 18 as the boot JDK, it produces class files that will 
>> run with JDK 11, using "--source 11 --target 11". The proposed change 
>> discussed here would update that in JavaFX 20 to "--source 17 
>> --target 17".
>>
>> 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 turns a bunch of existing data classes into records 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".
>>
>> Absent a compelling reason to remain stuck in the past, I plan to 
>> send out a pull request for this change next week.
>>
>> Comments are welcome.
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8290530
>>
>