Minimum JDK policy for OpenJFX

[Ty Young]

GTK4 was just released not that long ago. I don't know how much(if any 
at all) code is shared between versions, but having a tool like jextract 
might be useful for adding support for that. Just a guess.


Also, the bindings are different in that, for everything not a primitive 
in java(except boolean and char), you need to allocate memory and pass 
the address of the memory to the function(e.g. structs, unions, arrays). 
You also need to, depending on which ResourceScope is used, explicitly 
free your memory.


And, again, everything is in Java.


Maybe the ability to allocate off-heap arrays is useful somehow? Maybe 
to somehow reduce GC pressure when resizing the application or something?


On 5/25/21 3:59 AM, Nir Lisker wrote:
> I looked at jextract a while back. I got the impression that it's more 
> useful when you need to generate new bindings, at the very least 
> because there are fewer ways to make mistakes. Most of the work on 
> JavaFX has already been done in this area and the mistakes have been 
> found and fixed by now, so is there any substantial value in redoing 
> it with jextract?
>
> On Thu, May 20, 2021 at 12:25 AM Ty Young <youngty1997 at gmail.com 
> <mailto:youngty1997 at gmail.com>> wrote:
>
>     If you want to learn more about Panama you can read the JEP page:
>
>
>     https://openjdk.java.net/jeps/412 <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
>     <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 <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?
>     >>
>