How to re-initialize JavaFX from a hot loaded class inside a Swing application

I’ve run into a fairly niche problem involving JavaFX from what I can tell. As background I am writing a Burp Suite extension which is explained more here:

https://portswigger.net/burp/documentation/desktop/extensions

but the short of it is that the main application, which uses Swing for its UI, loads a user supplied jar, looks for a class which implements a specific interface, and calls it’s initialize method which is the first opportunity for your custom extension code to run.

The purpose of my extension is to provide a means of writing notes in markdown along with previewing said markdown. To do that I’m leveraging https://github.com/vsch/flexmark-java for the Markdown parsing, https://github.com/FXMisc/RichTextFX as the editor, and a JavaFX WebView for preview.

This works really well currently and all was smooth sailing until I tried to reload the extension. Burp Suite allows for load/unloading extensions without closing the main application. When my extension loads the first time, it initializes my UI like so:

 SwingUtilities.invokeLater(() -> {
                Platform.startup(() -> {
                burpNotesTab = new JFXPanel();
                customNotesTab = new CustomNotesTab();
                burpNotesTab.setScene(new  Scene(customNotesTab));
                api.userInterface().registerSuiteTab("Notes++",burpNotesTab);
                });
            });

Within the bowels of Platform.startup() it creates an instance of com.sun.javafx.tk.Toolkit which calls this during initialization:

            if (PlatformUtil.isWindows()) {
                loadMSWindowsLibraries();
            }

which calls:

    public static synchronized void loadLibrary(String libname) {
        if (!loaded.contains(libname)) {
            StackWalker walker = (StackWalker)AccessController.doPrivileged(() -> {
                return StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
            });
            Class caller = walker.getCallerClass();
            loadLibraryInternal(libname, (List)null, caller);
            loaded.add(libname);
        }

    }

within com.sun.glass.utils.NativeLibLoader which eventually calls System.load for all the JavaFX dlls.

Now normally this would be fine because any subsequent call to Platform.startup() or runLater would skip the library load due to the loaded.contains check. But, because unloading an extension destroys all instances of these classes, on reload the loaded list is empty even though the libraries are still loaded. This causes a slew of:

 java.lang.UnsatisfiedLinkError: Native Library ....openjfxcache21+31amd64prism_sw.dll already loaded in another classloader

errors because the new classLoader created for the reloaded extension tries to call System.load again.

To try and combat this I tried implementing my own basic classLoader with a loadClass method like so:

    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                if (name.startsWith("notesplusplus.BurpNotesTab") || name.startsWith("com.sun.glass.utils") || name.startsWith("com.sun.javafx.tk")) {
                    c = findClass(name);
                } else {
                    c = super.loadClass(name, resolve);
                }
            } catch (ClassNotFoundException e) {
                c = super.loadClass(name, resolve);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }

which ensures my classLoader loads my own, the NativeLibLoader, and Toolkit classes instead of the application classLoader. Through inherited classloading this also ensures the DLLs are loaded by me as well. This solution almost works. When unloading the extension all of my classes are garbage collected except my custom classLoader which holds refs to the loaded libraries so we’re still back to the same problem just that now I’m the holder not the application classloader.

What is keeping a reference to my classLoader, and how to solve it, is a mystery to me hence this question. When I look at a heap dump in MAT or VisualVM it tells me that my classLoader is a GC root:

Class Name                                             | Shallow Heap | Retained Heap
--------------------------------------------------------------------------------------
notesplusplus.CustomClassLoader @ 0xa66f2518 JNI Global|           72 |     1,271,656
--------------------------------------------------------------------------------------

so something in native code is holding a ref to my classLoader. On extension unload I call .getChildren().clear() and getScene().getWindow().hide() on the Vbox containing all the components. Then call Platform.exit() so I’m not sure what more I can do or should do to close down the JavaFX context.

The JavaFX platform is not restartable once started in the JVM

From the documentation on the JavaFX Lifecycle:

A JavaFX Application should not attempt to use JavaFX after the FX toolkit has terminated.

So don’t try to do that.

For more info, see the wumpus example, which demonstrates reusing the JavaFX platform at different times after all JavaFX scenes and windows are closed, without exiting the platform.

Module layers and services

JavaFX is supposed to be loaded as modules

The JavaFX classes must be loaded from a set of named javafx.* modules on the module path.

There may be a way to dynamically load and unload the JavaFX modules:

At a high-level, the module system is not dynamic in the sense that
individual modules can not be unloaded or replaced in a running VM.

However, you can use the API, specifically
java.lang.module.Configuration and java.lang.ModuleLayer to create
dynamic configurations of modules and instantiate them in a running VM
as a layer of modules.

In your scenario, then you may create a layer
of modules with modules B and C. This layer of modules will be
GC’ed/unloaded once there are no references to them.

As you have already noted in your question, JavaFX relies on a combination of both Java and native libraries. So, even though the module layer replacement approach may work for the Java code, there may still be some difficulties you might need to address or work-around in regards to the handling of the native libraries.

As noted by one of the JPMS leads:

this is an advanced topic and it’s probably better to spend time mastering the basics, including services, before getting into dynamic configurations and module layers.

I guess you are at the advanced topic stage, where you might want to expend some effort to investigate this.

Potential solutions

As far as I can see your options are:

Add the JavaFX modules to the module path of your main app, start the JavaFX platform on app startup or the first time you need JavaFX and exit the JavaFX platform when your app shuts down (seems best to me).

Spawn a new process which runs a new JVM instance with JavaFX when you need it and terminates the JVM when you are done.

Try to hack the system to allow JavaFX to run in an unsupported way where you start and stop the toolkit (the current approach in your question).

Eclipse provide an OSGi interface for JavaFX. It may be used to support their e(fx)clipse plugin. I don’t know if that interface allows for the dynamic reload facilities that are part of OSGi, but it is something you could investigate if so inclined.

I know that no option is what you intend, but those are the solutions I can envision.

In your case some of those potential solutions may not be feasible because you state:

The larger application running my extension, which I can’t edit, runs my extension in a new classLoader every time.

FAQ

That just seems surprising to me that there’s no way to use JavaFX in a “hotload” manner. The fact that “if you launch a JavaFX scene and destroy it, you can’t use it again until you destroy the whole process” seems like a bug.

It is not “launching a scene and destroying it” that means you can’t use JavaFX again, it is shutting the JavaFX platform down.

If you want the JavaFX Platform to continue to be available after the last window is closed, then call:

Platform.setImplicitExit(false);

and explicitly stop the JavaFX platform with

Platform.exit();

but only when you know you will never use it again.

Hmm, yea the crux of this issue is that the NativeLibraries can only be loaded once and my classLoader way of loading them would ensure they are removed when my extension is unloaded if this Global JNI ref would go away and let it get GC’ed.

The Platform.exit() and such were just attempts at clearing whatever was holding onto it.

JavaFX seems generally designed around the principle that it’s only ever going to call the setup methods once in a processes lifetime and within the same classloader.

Yeah, most likely.

For a period, JavaFX was part of the Oracle JDK and tightly integrated with the JVM launcher, where the launcher would detect a JavaFX application, initializing JavaFX components at JVM startup and shutting them down at JVM shutdown.

Seperation from the JVM launcher and addition of finer grained app lifecycle control in the Platform class was added later, but never for platform exit and restart (at least up until JavaFX 22).

Filed under: Kiến thức lập trình - @ 06:08

Thẻ: javaswingjavafxclassloader

Thiết kế website giá rẻ

Danh mục

How to re-initialize JavaFX from a hot loaded class inside a Swing application

The JavaFX platform is not restartable once started in the JVM

Module layers and services

Potential solutions

FAQ