[12] RFR: JDK-8209966: Update minimum boot JDK to 11

[Ty Young]

On 9/24/18 2:12 AM, Johan Vos wrote:
>
>
>     > And it's only going to get worse as time goes on. Would it not be
>     > possible to support up until the last JDK LTS(Starting at 11)
>     release
>     > for building JavaFX? I feel like maybe that would be more
>     reasonable.
>
>     This is a good question, and maybe in the future we might not be so
>     quick to do this...or maybe we will.  We should discuss this
>     before we
>     get to this point for JavaFX 13, a little less than six months
>     from now.
>     The choices for the model are:
>
>     1. Allow building JavaFX N with either JDK N-1 or JDK N.
>     2. Allow building JavaFX N with the most recent LTS or later.
>
>     Choice #1 will allow JavaFX to better keep pace with JDK features
>     (API
>     or language features). Choice #2 will allow JavaFX to build and
>     run with
>     the most current, stable JDK LTS at the cost of not being able to use
>     newer JDK features.
>
>
> One of the reasons Java is moving to a fast release cadence is because 
> today, this is required to stay relevant in a fast-changing landscape.
> I think we need to do the same with JavaFX. We should be able to 
> leverage the latest and greatest advances in the JDK, since this will 
> allow JavaFX to move fast as well, which is required to stay relevant.
>

Maybe it's because I don't work for a large corporation, but I don't see 
this supposed "fast-changing" landscape. To me, it just looks like Java 
is trying to appeal to all the people from Python/C++/other languages 
who can't or have a hard time writing object oriented code by 
introducing a more lazy "functional" and "concise" way of programming. 
The amount of actual meaningful updates to the language in 10 and 11 in 
my eyes is fairly small, which is somewhat expected with the faster 
release cycles. If there was actually a "fast-changing" landscape, I 
would think that there would more meaningful and useful updates rather 
than the 50/50 "functional and/or concise"/other misc updates that has 
been the case for JDK 10 and 11.


Personally, whatever was updated that resulted in Netbeans properly 
using the OS's Look and Feel was the only worthwhile update of the 
entire JDK 11 release IMO, but I digress.


To be clear, I'm not that concerned about breaking compatibility with 
older versions of the JDK because of API updates/introductions/removals 
or new, better tools being introduced. I'm more concerned about 
backwards compatibility being broken for stupid reasons like new lazy 
language updates that have no actual value or can be done with older 
compatible ways just because people want to be lazy, "functional", and 
"concise" which has become a bit of a hot trend lately.


> If you want to run on the latest stable JDK LTS, the logical 
> consequence seems to me you use the latest stable JavaFX LTS. There is 
> LTS support available for both Java and JavaFX 11 and they are pretty 
> well aligned.
>

That's all fine and dandy except for the fact that you can't guarantee 
what JRE is being run if you haven't moved to Java 9 modules. What do 
you do, wait a few months after a new LTS is out and then update your 
application with new JDK/JavaFX features and say "tough luck" to anyone 
who is still using a previous LTS? What if a user has a newer JRE 
installed with a feature that exists on the previous LTS removed but not 
their newer JRE that JavaFX LTS depends on?


I've never tried it, but I guess you could prompt the user to download a 
compatible JRE via a Swing GUI and use that to launch the application 
via a launcher... but that's just awful for so many different reasons.


> Having said that, there is no point in moving forward just for the fun 
> of it. We also have to distinguish between changes in the VM or in the 
> core Java API's.
> My opinion is that if a new feature is added to JDK N, we can really 
> take advantage of it in JavaFX (N+1).
> In some cases, there won't be new features relevant to OpenJFX. But 
> even then, I don't think we can't change our rules on a per-release 
> case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; 
> but JavaFX 15 works with Java 14 and Java 15 and not with Java 13).
>
> In general, I think developers updating from JavaFX 11-12-13 are also 
> capable of updating the JDK from 11-12-13, so I prefer the coupling
>
> 1. Allow building JavaFX N with either JDK N-1 or JDK N.
>
> - Johan
>