Minimum JDK policy for OpenJFX

[Ty Young]

If you want to learn more about Panama you can read the JEP page:


https://openjdk.java.net/jeps/412


You can also join the panama-dev list and ask questions:


https://mail.openjdk.java.net/mailman/listinfo/panama-dev


Biggest things for JavaFX that I can think of is jextract, a tool for 
generating Java headers from a C header, and having all binding code 
written in Java. It may be easier to upgrade to newer GTK versions using 
Panama as there is no C shim required and the bindings are, again, 
generated for you. jextract does have issues, one of which is that any 
binding generated using it are platform-specific even if the library 
itself is cross-platform. You can make bindings by hand that are 
cross-platform if you want, though.


Speaking of GTK, when is JavaFX going to support GTK4?




On 5/18/21 4: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.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?
>>