Problem running JavaFX in maven plugins

[Dan Armbrust]

As a followup, the easiest workaround I found is this silly hack:

                      String s = System.getProperty("javafxHack");
                      int i = 0;
                      if (!StringUtils.isBlank(s))
                      {
                         i = Integer.parseInt(s);
                         i++;
                      }
                      System.setProperty("javafxHack", i + "");
                      System.setProperty("javafx.version", "mavenHack" + i);

Which I run before calling PlatformImpl.startup();
This way, each classloader that launches JavaFX gets its own copy of the dll.

It would be nice if the JavaFX code itself handled the dll's better to not have this issue 
- this is a regression from JDK 8.

But I do realize its probably a rare usecase... I run into it because I have multiple 
instantiations of a plugin that runs during a maven lifecycle that utilizes the tasks API, 
among other things.

But this will also break for anyone that tries to use parts of JavaFX in a server like 
tomcat where classloaders are isolated. But that might not be a common issue either unless 
the very old feature request about JavaFX not supporting running Headless get fixed.

I currently use our own hacked implementation of a ToolKit to inject when running 
headless, in order to make the tasks API work.

Dan



On 12/31/2018 09:54 PM, Dan Armbrust wrote:
> Hi,
>
> I'm trying to migrate a codebase to JDK 11 / OpenJFX, and have run into an issue I 
> didn't have under JDK 8.
>
> We have a complex maven build process - parts of which include building our own maven 
> plugins, and then executing those plugins in a different portion of the build.
>
> Maven uses isolated Plugin Classloaders for each plugin execution: 
> https://maven.apache.org/guides/mini/guide-maven-classloading.html
>
> When my plugin executes, its going down a path that needs to start up the JavaFX 
> subsystem - mostly to get support for tasks and such (we are actually building headless, 
> with a hack of a HeadlessToolkit shimmed in to make JavaFX actually work headless) but - 
> it would appear that because some other class loader in my build process already hit the 
> JavaFX startup once... I fail on a native library load:
>
> Loading library glass from resource failed: java.lang.UnsatisfiedLinkError: Native 
> Library /home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another classloader
> java.lang.UnsatisfiedLinkError: Native Library 
> /home/darmbrust/.openjfx/cache/11/libglass.so already loaded in another classloader
>         at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2456)
>         at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
>         at java.base/java.lang.Runtime.load0(Runtime.java:767)
>         at java.base/java.lang.System.load(System.java:1831)
>         at 
> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:205)
>         at 
> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:185)
>         at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:157)
>         at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
>         at com.sun.glass.ui.Application.loadNativeLibrary(Application.java:110)
>         at com.sun.glass.ui.Application.loadNativeLibrary(Application.java:118)
>         at com.sun.glass.ui.gtk.GtkApplication.lambda$static$2(GtkApplication.java:109)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at com.sun.glass.ui.gtk.GtkApplication.<clinit>(GtkApplication.java:108)
>         at 
> com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(GtkPlatformFactory.java:41)
>         at com.sun.glass.ui.Application.run(Application.java:144)
>         at com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:258)
>         at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:269)
>
> Any suggestions on how to deal with this?
>
> I'm running on linux with:
> openjdk 11.0.1 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
>
> I'm going to try this hack and see if it works: 
> https://stackoverflow.com/questions/28369180/multiple-maven-plugin-dependencies-native-library-already-loaded-in-another-cl
>
> But it would be nice to have a proper solution for this.
>
> Also, on a completely unrelated note, where the heck is the JavaFX bug tracker these 
> days?  There seems to be no end to confusing information out there about where the bug 
> tracker is, multiple github mirrors have trackers, and the place that should clarify 
> this says nothing: https://openjfx.io/
>
> Multiple Oracle pages still point to the Jira, many other pages point to the 
> bugreport.java.com, others point to https://bugs.openjdk.java.net/ but that shows no 
> javafx project.
>
> Is this one official now? https://github.com/javafxports/openjdk-jfx/issues
>
>
> Thanks,
> Dan
>