Re: Minimum JDK policy for OpenJFX

[Ty Young]

On 5/30/21 5:19 PM, John Neffenger wrote:

On 5/19/21 1:17 PM, Ty Young wrote:
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.


JavaFX has been doing its own manual form of Project Panama since 
2014. Look for the string "extends C.Structure" in the following two 
files:


https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java 



https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDSystem.java 



In both cases, the technique was used to let JavaFX bypass the header 
file 'mxcfb.h' from NXP (formerly Freescale).


I'm looking forward to replacing those hard-coded offsets with the 
tools from Project Panama. In fact, I'm hopeful that Project Panama 
will let me remove all of the native C code from the Monocle EPD 
platform.



Now that you pointed it out, JavaFX uses SecurityManager:


https://github.com/openjdk/jfx/blob/5e6d4429159e3fab9ec0aab9720393850d179710/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/C.java#L40


Which is being deprecated. Panama has its own runtime flag to enable 
native access not tied to SecurityManager.



The C class native implementation can be replaced with Panama easily. A 
MemorySegment can be viewed using a ByteBuffer via:



MemorySegment segment = MemorySegment.allocateNative(8, 
ResourceScope.newImplicitScope());


ByteBuffer buffer = segment.asByteBuffer();


asByteBuffer() doc says it wraps the MemorySegment, so I'm guessing it 
has a strong reference and memory is freed once the buffer and segment 
are no longer referenced.



If someone wanted to try swapping out JavaFX's native implementation 
with Panama, this would be a good place to start IMO.





John

Re: Minimum JDK policy for OpenJFX

[John Neffenger]

On 5/19/21 1:17 PM, Ty Young wrote:
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.


JavaFX has been doing its own manual form of Project Panama since 2014. 
Look for the string "extends C.Structure" in the following two files:


https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java

https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDSystem.java

In both cases, the technique was used to let JavaFX bypass the header 
file 'mxcfb.h' from NXP (formerly Freescale).


I'm looking forward to replacing those hard-coded offsets with the tools 
from Project Panama. In fact, I'm hopeful that Project Panama will let 
me remove all of the native C code from the Monocle EPD platform.


John

Re: 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 > wrote:


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
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:
  

Re: Minimum JDK policy for OpenJFX

[Nir Lisker]

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  wrote:

> 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.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?
> >>
>

Re: [External] : Re: Minimum JDK policy for OpenJFX

[Nir Lisker]

Looks like the new features that we can use are:
- Switch expressions
- Records
- Text blocks
- Pattern matching for instanceof

None of them seem pressing. When we get the more complete set of pattern
matching (with switch, sealed classes, guards...) it will probably be
enough to merit an update.

On Wed, May 19, 2021 at 6:16 PM Kevin Rushforth 
wrote:

> These are all excellent points. I would add that while a new language
> feature would be the biggest reason to update, there could be new JDK API
> that we would want to use as an argument type or return type in a new FX
> API. I'm not aware of any in the JDK 12-16 range (at least not ones that
> don't also have language changes such as records), but it has happened
> before.
>
> So taking all of this into account, it seems that unless someone wants to
> make an argument for a feature (language or API) from JDK 12 or later that
> we need to use in JavaFX 17, it seems unlikely that we will bump the
> minimum.
>
> -- Kevin
>
>
> On 5/19/2021 7:35 AM, Johan Vos wrote:
>
> Hi,
>
> This is an important and good discussion, and I've read a number of valid
> points. To reiterate what I've always stated:
> * we don't want to increase the base (JDK) version just for the sake of
> increasing
> * we don't want to lose significant benefits (or developer productivity)
> by sticking with old versions.
>
> This comes down to the question that is indeed the most important: are
> there *language* features in JDK 12 or higher that would improve the
> quality of OpenJFX? Clearly we're not talking about runtime improvements,
> as it's up to the developer/use to choose a runtime.
>
> Personally, I don't see many possible huge improvements in the JavaFX API
> by using JDK 12+ features, but I might be missing things.
>
> Related to the LTS discussion (disclaimer: just my personal opinion here,
> not an "official" Gluon statement): I don't see that as the primary reason
> for bumping the dependency. The thing we want to avoid though is that there
> is a jump in the required Java SDK inside an LTS family (e.g. JavaFX 11 has
> Java 11 as its base, and JavaFX 11.0.12 will have Java 11 as its base as
> well).
> This might become harder in the future, as I can imagine Valhalla having a
> bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is an LTS
> version and it starts being based on Java 11, and in case we decide to bump
> the base level for JavaFX 20 to e.g. Java 19, it might become much harder
> to backport issues into the 17-tree.
> In that spirit, it would make sense to bump the version for 17, but it
> seems a bit artificial as the major new language benefits (to OpenJFX) in
> the JDK might occur in between 2 LTS families.
>
> - Johan
>
>
> On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> 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
>> > 

Re: 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 
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?

Re: [External] : Re: Minimum JDK policy for OpenJFX

[Kevin Rushforth]

These are all excellent points. I would add that while a new language 
feature would be the biggest reason to update, there could be new JDK 
API that we would want to use as an argument type or return type in a 
new FX API. I'm not aware of any in the JDK 12-16 range (at least not 
ones that don't also have language changes such as records), but it has 
happened before.


So taking all of this into account, it seems that unless someone wants 
to make an argument for a feature (language or API) from JDK 12 or later 
that we need to use in JavaFX 17, it seems unlikely that we will bump 
the minimum.


-- Kevin


On 5/19/2021 7:35 AM, Johan Vos wrote:

Hi,

This is an important and good discussion, and I've read a number of 
valid points. To reiterate what I've always stated:
* we don't want to increase the base (JDK) version just for the sake 
of increasing
* we don't want to lose significant benefits (or developer 
productivity) by sticking with old versions.


This comes down to the question that is indeed the most important: are 
there *language* features in JDK 12 or higher that would improve the 
quality of OpenJFX? Clearly we're not talking about runtime 
improvements, as it's up to the developer/use to choose a runtime.


Personally, I don't see many possible huge improvements in the JavaFX 
API by using JDK 12+ features, but I might be missing things.


Related to the LTS discussion (disclaimer: just my personal opinion 
here, not an "official" Gluon statement): I don't see that as the 
primary reason for bumping the dependency. The thing we want to avoid 
though is that there is a jump in the required Java SDK inside an LTS 
family (e.g. JavaFX 11 has Java 11 as its base, and JavaFX 11.0.12 
will have Java 11 as its base as well).
This might become harder in the future, as I can imagine Valhalla 
having a bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is 
an LTS version and it starts being based on Java 11, and in case we 
decide to bump the base level for JavaFX 20 to e.g. Java 19, it might 
become much harder to backport issues into the 17-tree.
In that spirit, it would make sense to bump the version for 17, but it 
seems a bit artificial as the major new language benefits (to OpenJFX) 
in the JDK might occur in between 2 LTS families.


- Johan


On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


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
>
> 

Re: [External] : Re: Minimum JDK policy for OpenJFX

[Johan Vos]

Hi,

This is an important and good discussion, and I've read a number of valid
points. To reiterate what I've always stated:
* we don't want to increase the base (JDK) version just for the sake of
increasing
* we don't want to lose significant benefits (or developer productivity) by
sticking with old versions.

This comes down to the question that is indeed the most important: are
there *language* features in JDK 12 or higher that would improve the
quality of OpenJFX? Clearly we're not talking about runtime improvements,
as it's up to the developer/use to choose a runtime.

Personally, I don't see many possible huge improvements in the JavaFX API
by using JDK 12+ features, but I might be missing things.

Related to the LTS discussion (disclaimer: just my personal opinion here,
not an "official" Gluon statement): I don't see that as the primary reason
for bumping the dependency. The thing we want to avoid though is that there
is a jump in the required Java SDK inside an LTS family (e.g. JavaFX 11 has
Java 11 as its base, and JavaFX 11.0.12 will have Java 11 as its base as
well).
This might become harder in the future, as I can imagine Valhalla having a
bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is an LTS
version and it starts being based on Java 11, and in case we decide to bump
the base level for JavaFX 20 to e.g. Java 19, it might become much harder
to backport issues into the 17-tree.
In that spirit, it would make sense to bump the version for 17, but it
seems a bit artificial as the major new language benefits (to OpenJFX) in
the JDK might occur in between 2 LTS families.

- Johan


On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth 
wrote:

> 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
> > 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 

Re: [External] : Re: Minimum JDK policy for OpenJFX

[Kevin Rushforth]

I missed seeing this reply yesterday. We can't bump the minimum to JDK 
17 until at least JavaFX 18 without changing our policy that JavaFX N is 
able to build and run with JDK N-1. If we were to change that we would 
also need to delay our release to be after JDK 17 date (currently JavaFX 
N is released a week ahead of JDK N). Also, there are technical 
challenges building with the JDK 17 EA as a moving target (at least for 
the next few weeks) that we would need to deal with. In summary, I would 
not want to propose this.


-- Kevin


On 5/18/2021 8:33 AM, Michael Strauß wrote:

Sounds good, although it is a bit unfortunate that sealed classes will
only be un-previewed in JDK 17. I think this feature has great value
for reasoning about code, in particular for library development. Do
you think we could bump it directly to JDK 17, which I think is very
fitting because it's the next LTS release, after all.

Am Di., 18. Mai 2021 um 17:17 Uhr schrieb Kevin Rushforth
:

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?

Re: 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
ebre...@gmail.com (mailto:ebre...@gmail.com)


On May 18, 2021 at 4:42:45 PM CDT, Nir Lisker 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 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?

Re: Re: Minimum JDK policy for OpenJFX

[Eric Bresie]

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  (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  (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?
> >
> >

Re: [External] : Re: Minimum JDK policy for OpenJFX

[Kevin Rushforth]

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 
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?

Re: Minimum JDK policy for OpenJFX

[Nir Lisker]

>
> 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 
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?
>
>

Re: Minimum JDK policy for OpenJFX

[Chuck Davis]

I use JFX with NetBeans every day with no problems.  NetBeans 12.3 and JFX
16 on OpenJDK16

SceneBuilder creates the dialogs.  NetBeans writes the code.  The NB JFX is
too old.  You have to update from Maven (which is, itself, still stuck on
old versions of JFX -- hasn't been updated for some time, unfortunately).

BUT, using JFX with NetBeans is not a problem here.

On Tue, May 18, 2021 at 1:52 PM Matthias Bläsing 
wrote:

> Hi,
>
> Am Dienstag, dem 18.05.2021 um 08:17 -0700 schrieb Kevin Rushforth:
> >
> > 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?
>
> I'd like to be able to use JavaFX with NetBeans. Everytime I tried to
> reach a state where it became usable I hit issues in FX and the latest
> crasher bug will only be fixed in 17 and at this time NetBeans still
> tries to stretch from 8 to 16 (ok, 9 and 10 were left in the dust).
>
> IMHO stability and compatibility with the past is a feature, not a bug
> and the "lets brake it" attitude I feel the last years in the java
> landscape is irritating.
>
> Greetings
>
> Matthias
>
>

Re: Minimum JDK policy for OpenJFX

[Matthias Bläsing]

Hi,

Am Dienstag, dem 18.05.2021 um 08:17 -0700 schrieb Kevin Rushforth:
> 
> 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?

I'd like to be able to use JavaFX with NetBeans. Everytime I tried to
reach a state where it became usable I hit issues in FX and the latest
crasher bug will only be fixed in 17 and at this time NetBeans still
tries to stretch from 8 to 16 (ok, 9 and 10 were left in the dust).

IMHO stability and compatibility with the past is a feature, not a bug
and the "lets brake it" attitude I feel the last years in the java
landscape is irritating.

Greetings

Matthias

Re: Minimum JDK policy for OpenJFX

[Michael Strauß]

Sounds good, although it is a bit unfortunate that sealed classes will
only be un-previewed in JDK 17. I think this feature has great value
for reasoning about code, in particular for library development. Do
you think we could bump it directly to JDK 17, which I think is very
fitting because it's the next LTS release, after all.

Am Di., 18. Mai 2021 um 17:17 Uhr schrieb Kevin Rushforth
:
>
> 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?
>

Re: Minimum JDK policy for OpenJFX

[Kevin Rushforth]

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?