What's the story with JavaFX nowadays? I'm not a Java dev, but from a user perspective it's a bit of a PITA since OpenJDK doesn't (?) package JavaFX with it (and neither does the latest oracle JRE/JDK?). It seems to be open source but the main program I'm thinking of, an old-school raytracer for minecraft Chunky [0] requires it be packaged with the JDK, hence the requirement for Java 8.

Is this just laziness on the part of those devs to not package it up or is there something else going on?

[0] https://github.com/chunky-dev/chunky

Yes, this indeed looks like laziness of the developers to me. When the app was developed, JavaFX came pre-packaged with the JDK/JRE, so they still rely on it. Today, it should perhaps just be a regular dependency of your app and be part of your app.

If I were to build a Java desktop application today, I would even bundle the entire JRE, since you cannot assume that it is installed on most desktops anymore.

AFAIK you need to include JavaFX DLLs with your application and configure appropriate java.library.path. It's not laziness, JavaFX is not part of Java anymore, so you need to deploy it like any other native component.

JavaFX is no longer part of the core OpenJDK distribution, but it's not dead and gone, it's just maintained separately.

There's no need to stay on Java 8 to use JavaFX, although I'm not qualified to speak on whether it would be a lot of effort to upgrade a JavaFX application to a newer Java.

One issue is that I think Oracle forced package renames and, afaik, there’s no compatibility layer available for packages that expected the old Class Names. To my mind, this sort of defeats the purpose of the JVM’s universally unique symbol names.

I don't think so. They were named javafx... both before and after, no?

Doesn't sound like a real problem though. Renaming things is the easiest kind of change to accommodate.

I think I’m confusing it with the Java EE changes. However, renaming is only easy to accommodate if you have source access. The JVM’s model is portable binaries, so forcing renames breaks some of that model.

True, it would break binary compatibility.

JavaFX 15 API is compatible with that of JavaFX 8.

It does. JavaFX + Graal Native is even used to make native mobiles AFAIK.

My understanding is that JavaFX is discontinued and so that 'it happens to still work with Graal' is just a bonus. Things change over time, so unless there is a focus on things actually working and integrating, this won't last.

But please correct me if I'm wrong.

Oracle has in fact discontinued their support for JavaFX, and of course gave up on it long ago. It's apparently being supported by a tiny company 'Gluon' [1] so I'm wary to think that there will be any material progress comparable to a well supported platform.

[1] https://gluonhq.com/products/javafx/

Ok, meant to say they've signalled the fact they may not support in the future.

It seems however they are not really backing it, more or less, doing the least to simply not let it fall over. Which is material.