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