bell-sw/Liberica

Why this JavaFX 23 Fix is not Included in JDK 23.

Closed this issue · 6 comments

I just downloaded Liberica JDK 23 and found that this fix is not included in the JDK: openjdk/jfx#1236

It would be good to understand what has caused an impression that this fix is not included (as in, discuss the problem you observe). According to the release notes [1], source code [2], and test results, the fix is in.

[1] https://docs.bell-sw.com/liberica-jdk/23b38/general/release-notes/
[2] https://download.bell-sw.com/java/23+38/bellsoft-jdk23+38-src-full.tar.gz

Well. The windows build does have this fix.

image

But it does not work as expected on macOS arm using a packaged version by javapackager.

image

Meanwhile, I encounter the following error directly running it on macOS x64:

java.lang.RuntimeException: java.lang.IllegalAccessException: class anywheresoftware.b4j.object.JavaObject cannot access class com.sun.javafx.collections.VetoableListDecorator (in module javafx.base) because module javafx.base does not export com.sun.javafx.collections to unnamed module @6f793049

I think I will keep using the builds by openjdk for now.

While I'm not an expert with B4X, you may want to try to add #JavaCompilerPath to your app project attributes to make sure the app is compiled using JDK 23. Both your errors (on Mac M1 and x86_64) could easily be caused by not using the 23 javac (and/or not bundling the correct runtime with the app).

This is not related to compilation. Even if I compile with JDK 11, as long as I use the JRE 23 with the fix, it works.

Again, since I'm not an expert in B4X, it's hard to tell how the packaging of the runtime with the app is done. I just suggested to check that the runtime that is used to run the app is indeed 23. It's very easy to get confused by the compilation and packaging switches in various frameworks.

Anyway, here is a simple test openjdk/jfx#1236 (comment) that I used to check that the fix indeed works on Macs:
ALIGN

To move this forward, please submit an isolated case similar to that that demonstrates the problem you are observing.

Yes. This was my mistake. I have several JDKs installed:

$ ls /Library/Java/JavaVirtualMachines/
liberica-jdk-11-full.jdk	liberica-jdk-23-full.jdk
liberica-jdk-17-full.jdk	liberica-jdk-8-full.jdk

Then I used the following command to package it:

javapackager \
  -deploy -Bruntime=/Library/Java/JavaVirtualMachines/liberica-jdk-23-full.jdk/Contents/Home \
  -native image \
  -srcdir java \
  -srcfiles ImageTrans.jar \
  -outdir release \
  -outfile ImageTrans.jar \
  -appclass org.xulihang.imagetrans.main \
  -name ImageTrans \
  -title ImageTrans \
  -nosign \
  -v

But somehow, it still uses JDK 11 as the runtime.

So this issue can be closed as the fix is included.