Migrate JavaFX examples or retire them?

[keilw]

As we heard, Java 11 is not going to include JavaFX any more.

The JavaFX examples either have to be migrated to a successor project (Open FX or whatever) or retired over time if JavaFX itelf also ends up being archived.

[msgilligan]

I'm hearing that Java FX being decoupled from Java will be a good thing -- that it will evolve faster. Won't it just be an optional Maven dependency? By "migrate" do you just mean add the optional dependency?

[keilw]

Well it won't work with the JDK any more after Java 11. This is not a high prio issue since many people have not even moved to Java 7 but as soon as someone (@aalmiray hinted he'd love to help at the JavaLand unconference) establishes it in a new place after Oracle donated it (could take as long as NetBeans or JakartaEE) the dependency should be updated to ensure it'll work with any supported Java version.

[msgilligan]

Well it won't work with the JDK any more after Java 11

won't work with only the JDK any more after Java 11, right?

[aalmiray]

@msgilligan correct. OracleJDK 11 will ship without JavaFX. This is the same case as OpenJDK does right now, you must download OpenJFX as a separate binary. Starting with Java 11 we'll see releases of JavaFX that may or may not track the same release dates as OpenJDK; we're working on it.

[keilw]

@aalmiray Thanks for the input. Has the new place, namespace (e.g. if "javafx" may be preserved at least for existing modules like JakartaEE does) etc. been found already?

[keilw]

Marked it external because there is a dependency on a TBD JavaFX project.

[aalmiray]

No migration to a different space/brand is needed at the moment. JavaFX will continue being developed as part of the OpenJDK umbrella under OpenJFX.

[keilw]

If the community is allowed to do that like say DeviceIO (not sure, if that's still alive?) then it sounds like a good idea. Any chance you might get the RI of JSR 377 into that optional OJDK project or is Griffon the better option?

[aalmiray]

I think releasing an RI for JSR377 would be faster if Griffon is retrofitted with the new API rather than starting from scratch 😉

[keilw]

As long as the EC still exists and extends the lifeline (I see no Renewal Ballot 3 scheduled, but 13 months after the last one it should have been due by now) why not.

[Daniel-Dos]

Hello,

I'll do the migration / upgrade to OpenJavaFX 11.

in case I update it or create a new folder for it?

[msgilligan]

As far as I'm concerned I'd be happy to see the examples support OpenJFX 11 and later only.

[Daniel-Dos]

wondeful ,

I did the same here -> https://github.com/unitsofmeasurement/uom-demos/tree/master/javafx

[keilw]

We made this switch in the master/2.0 branch for UoM. I can't say, if the 1.x version of the Money JSR should already switch entirely or if we should have an OpenJFX 11 and JDK JavaFX 8 compatible version side-by side? Running in CI only makes sense for one. I am not opposed to keeping a javafx-java8 kind of module but disable it and use OpenJDK 11 to build the demos. Nothing keeps those who need the Java 8 compliant ones to run them, the minimum Java version would only be 11 for this one.

WDYT?

[Daniel-Dos]

Hi,

we can leave the two versions, however with java 11 disabled, as was done for the example javamoney-console-java10

[keilw]

Guess that (supporting JFX for Java 8 and 11+) might require profiles and the toolchain plugin, something that already works in other places, but is a bit complicated. I guess it is best to upgrade the JFX modules and use a minimum JDK like 11.

[keilw]

@aalmiray Btw what happened to 377?
It looks pretty dead, hasn't had a Renewal Ballot since 2 years ago, which is unacceptable for a JSR under JCP 2.11, but it still claims to be "active", will it be withdrawn or what's the plan?