Minimum JDK policy for OpenJFX

[Kevin Rushforth]

No. I've already done a full build and test using JDK 16 (and a full 
build using JDK 17 ea for that matter).

-- Kevin

On 5/18/2021 5:46 PM, Eric Bresie wrote:
> 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?
>>>