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

[Nir Lisker]

In my opinion, each JDK version should be evaluated according to its
benefits to JavaFX and not according to LTS, which is a foreign concept to
OpenJDK.

The JDK moved to a 6 months release plan so it can innovate faster without
waiting several years to release an important feature, and if we go with a
2 year minimum JDK-bump plan we will be working against this idea.
There are features that are mostly invisible to consumers of JavaFX,
usually those that come from Amber (algebraic data types and pattern
matching). We really don't need to bump the JDK version for every
incremental improvement of the 'switch' construct, but maybe when there is
enough accumulation. Also, these features decrease the amount of bugs, so
they pay dividends. For features that the consumers benefit from, like
large performance increases, it will be a disservice to hold users back 2
years when they can already use them in their own applications. If Valhalla
comes out with value classes that can improve performance dramatically
(should be benchmarked), or with generalized generics, or Panama comes out
with its foreign access API that JavaFX makes heavy use of, it would be
counterproductive to wait 2 years for these improvements.

The idea that an LTS JDK version is a good jumping point relies on the
assumption that users upgrade their JDK slowly (once every 2-3 years), but
their JavaFX fast (once every 6 months). That is, they want LTS for their
JDK but not for their JavaFX. If this assumption is correct for the
majority of cases, then there is merit to it. From what I see, companies
that rely on LTS for their JDK don't bump their other dependencies fast
either. The result of tying JavaFX to OpenJDK LTS will be that slow moving
consumers won't notice the change, and fast moving consumers will be
restricted. JavaFX LTS is already tied to OpenJDK LTS for a reason, and I'm
wondering what the reason is for tying non-LTS JavaFX to LTS OpenJDK. Maybe
Johan can give some statistics there.

On Wed, Jul 20, 2022 at 10:40 AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Dealing with the second question (when do we bump the version post-JFX20),
>
>
> On Tue, Jul 19, 2022 at 10:39 PM Philip Race <philip.race at oracle.com>
> wrote:
> ...
>
>> 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 ..
>>
>
> A possible idea is to apply the following 2 rules:
>
> 1) Whenever we bump the JDK version in JavaFX, it should be bumped to a
> JDK LTS version that is at least 1,5 years (minus 1 week) old at JFX
> release date.  This is exactly what will happen if the JFX 20 has a minimum
> JDK version of 17. This gives OpenJFX developers enough time to play with
> the new JDK features before using them in OpenJFX code.
>
> 2) We evaluate the options provided by the next LTS much in advance, and
> case by case (every 2 years), we discuss whether it is worth bumping the
> release (following rule 1)) .
>
> - Johan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220720/320f4ea0/attachment.htm>