You raise a good point about whether or not it should matter if a
version is (generally considered to be) an LTS release. I wasn't
suggesting that we necessarily wait until the next LTS to consider
picking up an important new feature, just that it could be one factor. I
also would be very interested to hear from Gluon on this point.
Your second point is the more interesting one. It comes down to the
question of when is there a new feature (or set of new features) that is
compelling enough that we want to require that version of the JDK in
order to be able to use it.
So for this specific discussion: Is there any language feature or API in
JDK 12 - 16 that is compelling enough that we would want to bump the JDK
in order to be able to use it?
-- Kevin
On 5/18/2021 2:42 PM, Nir Lisker 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.rushfo...@oracle.com <mailto:kevin.rushfo...@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?
