Minimum JDK policy for OpenJFX

[Eric Bresie]

Are there any deprecated or removed (1) (2) dependencies that could cause problems?

(1) https://jdk.java.net/16/release-notes#removed
(2) https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005191.html

Eric Bresie
Ebresie at gmail.com (mailto:Ebresie at gmail.com)

> On May 18, 2021 at 4:42:45 PM CDT, Nir Lisker <nlisker at gmail.com (mailto:nlisker at gmail.com)> wrote:
> >
> > there are some advantages in being able to run with the latest JDK LTS
> >
>
> One *potential* issue with this approach is that LTS is not defined in
> OpenJDK as far as I know. The LTS versions are a business decision of each
> distributor. For now, they have all aligned on 8, 11, 17, but nothing
> guarantees that this will stay so. What if different vendors LTS different
> versions? Suppose that Valhalla and Loom add very attractive features in
> JDK 19 (big performance enhancements, leads to big money savings on
> hardware, leads to economic incentives to use these, leads to requests to
> support these), now vendors can declare JDK 19 as LTS, and what will JavaFX
> do?
> In OpenJDK all versions are treated equally as it is a spec and not a
> business model. Should JavaFX be coupled to business models? Maybe Gluon
> has some insights since they give JavaFX LTS support.
>
> A second point, as Michael Strauß mentioned, is that maybe we should see
> what features are going to be delivered in the next versions and judge if
> there's something attractive enough for library developers to base our
> decision on. Sealed classes from Amber are certainly one of them. Panama
> might provide handy features for JavaFX's interfacing with native code,
> like Foreign Memory Access, though I didn't look into it in detail.
> Valhalla is certainly too far away to consider, and Loom is rather
> irrelevant for JavaFX and GUIs in general.
> If anyone has insights into relevant upcoming features I'll be happy to
> learn.
>
> - Nir
>
> On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth <kevin.rushforth at oracle.com (mailto:kevin.rushforth at oracle.com)>
> wrote:
>
> > A very timely question. I was already planning to raise this as a
> > discussion after we update our boot JDK to JDK 16 (blocked by the
> > in-progress gradle 7 update), which I hope to do later this week.
> >
> > I think that this is the right time to consider bumping the minimum
> > required version to run JavaFX 17 to JDK 16, which would allow us to
> > start using APIs and language features from JDK 12 through JDK 16
> > inclusive.
> >
> > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In
> > practice, though, we don't bump it for each release, as there are some
> > advantages in being able to run with the latest JDK LTS. Since JavaFX 17
> > will release at roughly the same time as JDK 17 LTS, I can't think of a
> > good reason to not update our minimum.
> >
> > Comments?
> >
> > -- Kevin
> >
> >
> > On 5/18/2021 7:59 AM, Michael Strauß wrote:
> > > Currently, JDK 11 is required for the latest version of OpenJFX. What
> > > is the policy for bumping this requirement? Does it always correspond
> > > to the latest JDK LTS release (the next of which will be JDK 17), or
> > > is it independent from the release cycle of OpenJDK?
> >
> >