[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [External] : Re: Minimum JDK policy for OpenJFX
From:       Nir Lisker <nlisker () gmail ! com>
Date:       2021-05-25 8:56:44
Message-ID: CA+0ynh_N=2BKio1dg-uzmA4s2=wtE9w8Zi9dpigvdU09eDRBug () mail ! gmail ! com
[Download RAW message or body]

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 <kevin.rushforth@oracle.com=
>
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 tha=
t
> 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 reaso=
n
> for bumping the dependency. The thing we want to avoid though is that the=
re
> is a jump in the required Java SDK inside an LTS family (e.g. JavaFX 11 h=
as
> 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 bu=
mp
> 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.rushforth@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=C3=9F mentioned, is that maybe we sho=
uld
>> > 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@oracle.com <mailto:kevin.rushforth@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 minimu=
m
>> >     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=C3=9F 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?
>> >
>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]