javafxStaticSdkVersion misaligned versions & not documented

[credmond]

javafxStaticSdkVersion has a default of 21-ea+11.1. Why is it stuck there?

What other possible versions are there and why aren't they documented anywhere, and why doesn't the available static libraries actually line up with actual public JFX versions (to keep things less confusing)?

E.g., 21-ea+11.1 isn't listed here:

https://mvnrepository.com/artifact/org.openjfx/javafx

... and none of the versions I've tried that are listed there, such as 21.0.2, are available as "static" libs:

https://download2.gluonhq.com/substrate/javafxstaticsdk/openjfx-21.0.2-linux-x86_64-static.zip ... does not exist.

[davidgiga1993]

It would also be great if there would be compile instructions so we can just compile the libraries ourself

[samypr100]

Note, there should be a build for 21.0.1, but likely not 21.0.2

e.g. https://download2.gluonhq.com/substrate/javafxstaticsdk/openjfx-21.0.1-linux-x86_64-static.zip

I mostly find these by trial an error 😅

[credmond]

@johanvos @jperedadnr

Can the list of available static libs be made publicly available somehow? Or allow
https://download2.gluonhq.com/substrate/javafxstaticsdk to list the contents?

I'm now encountering a big issue because the ObservableValue class in the static openjfx-21-ea+11.2 release, does not contain subscribe() methods, (but these do exist in Jfx21 releases -- it was a major feature of that release).

This version is the substrate default for us stuck on Java17/JFX21 and it doesn't line up with the version 1+ of officially released JFX21.

[credmond]

As samypr100 said, static libs openjfx 21.0.1 seems to exist, but not .2, .3, .4, .5....

Also, all of the commits to substrate always seem to refer to EA versions, but how do people pick stable version in general if there's no builds for them (of if they don't know about them)?

Curious on the expected process...

[johanvos]

True, it is a bit messy. Substrate needs to align 3 components (actually more, but the others are easier):

• Java class libs, from OpenJDK
• GraalVM AOT + VM, from GraalVM
• JavaFX native libs, from OpenJFX

The first 2 are the hardest to align, and they need to match exactly. The native code for e.g. libjava.a comes from OpenJDK, and it needs to match the java code from GraalVM. There is no 1-1 relation between the 2, so we take 2 tagged versions, and fix the incompatibilities in Substrate. JavaFX is the easier one, as both the Java and the native code come from OpenJFX. We typically use the latest "release" that maps to the tag-points of OpenJDK/GraalVM, and in most cases that is an EA release.

That is not a great approach, it's incredibly hard to maintain, and as you observe, it confuses developers.
It is one of the reasons we are trying to align everything we have with openjdk/jdk.
In the meantime, it would indeed help if we have better documentation on what versions are released.

[johanvos]

It would also be great if there would be compile instructions so we can just compile the libraries ourself

I 100% agree with this. Unfortunately, writing the compile instructions is the hardest thing. As I describe above (#1242 (comment)), it is sort of a trial/error trying to compile GraalVM native image and OpenJDK, where it needs to align for iOS/Android in the first place, and the desktop platforms preferably as well.
One of the difficulties is the fact that the boundaries between GraalVM and OpenJDK are undefined, leading to:

• GraalVM can add a required native function at any point in development, and we need to implement that on ios/android.
• the low-level Java api's can add/remove native functions at any point in development as well (that doesn't break the Java API), so we need to implement those on ios/android.

We have a number of dummy files in Substrate that deal with this, and there are ugly #ifdefs and changes all over the place, which make every release a separate project. I don't see how we can automate that process, it's just that we're happy when it works, and ship it.

As I wrote on the other comment, that is not how it should be, hence our work on aligning everything on 1 base.

[credmond]

Thanks for the weekend reply @johanvos.

I probably thought releasing JavaFX patch releases such as 21.0.2, .3, .4, or .5, as static libs. would have been a fairly routine build process (i.e., little to no further coding needed / no changes to substrate). I just thought it was about changing the shared libs to static libs and sticking them in a ZIP.

I also long forgotten that substrate doesn't or look at or care about the JFX version of your project's dependencies -- e.g., I have been using 21.0.4 sort of assuming that that's what substrate would be using (and pulling down as static libs).

[credmond]

@johanvos @jperedadnr

Can someone explain?

21.0.1 (e.g., https://download2.gluonhq.com/substrate/javafxstaticsdk/openjfx-21.0.1-linux-x86_64-static.zip):

javafx.version=21.0.1-internal
javafx.runtime.version=21.0.1-internal+6-2023-10-17-171512
javafx.runtime.build=6

Note the date, it seems to be older than 21-ea+11.2:

javafx.version=21-internal
javafx.runtime.version=21-internal+11.2-2024-03-05-115952
javafx.runtime.build=11.2

But 21-ea+11.2 has a class called ObservableValue which is missing subscribe() methods.

Also, 21.0.1 seems to have serious performance problems. Quite possibly the CSS bug I read about (https://bugs.openjdk.org/browse/JDK-8322795).

So if 21-ea+11.2 is newer than 21.0.1, why it is missing ObservableValue.subscribe()...? E.g., it doesn't have these changes: openjdk/jfx@6961016#diff-daf1d51638933f2dce3b6538d13c3a7e7a03e23792dc3879a38055ef665697dd

But it was built in 2024, and has the CSS/performance bug fix changes? None of this makes sense. Can't seem to catch a break here.

Is there any chance you can do a static lib build for the latest 21 version and mention/document this stuff somewhere? It isn't going to entail any native function changes, surely -- just a build.