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 ebre...@gmail.com (mailto:ebre...@gmail.com) > On May 18, 2021 at 4:42:45 PM CDT, Nir Lisker <nlis...@gmail.com > (mailto:nlis...@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.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? > > > >
