Question Details

No question body available.

Tags

maven javafx

Answers (2)

May 20, 2026 Score: 3 Rep: 31 Quality: Medium Completeness: 60%

jdk.jsobject was always a JDK module that only existed to serve javafx.web. It was deprecated in JDK 24 and removed in JDK 26. In a modular project the JavaFX Maven plugin places jars on the module path, so the jdk-jsobject-26.0.1.jar bundled with JavaFX is picked up automatically as an upgrade module. In a non-modular project those jars land on the classpath, so the module system never sees the bundled replacement hence the FindException. To fix it pass --upgrade-module-path via the plugin:

    
        org.openjfx
        javafx-maven-plugin
        0.0.8

default-cli

com.nowhere.mavenprojectseven.App

--upgrade-module-path ${settings.localRepository}/org/openjfx/jdk-jsobject/26.0.1/jdk-jsobject-26.0.1.jar

The --upgrade-module-path flag tells the JVM to substitute the JavaFX-bundled jdk.jsobject for the missing JDK module. The path above resolves to the jar already downloaded by Maven into your local repository.

May 20, 2026 Score: 0 Rep: 51,341 Quality: Medium Completeness: 100%

Removal of jdk.jsobject from the JDK

The jdk.jsobject module was deprecated-for-removal in Java 24 and has been removed in Java 26. Since JavaFX 24 it is now included with JavaFX. See the following CSRs for more information.

Affect on JavaFX Applications

Java 24 & 25

When using Java 24 or Java 25 you need to ensure that JavaFX's jdk.jsobject module is being used instead of the deprecated one in the JDK. From the release notes of JavaFX 24:

The jdk.jsobject Module is Now Included with JavaFX

The jdk.jsobject module, which is used by JavaFX WebView applications, is now included with JavaFX, replacing the JDK module of the same name. The jdk.jsobject module is deprecated as of JDK 24, and will be removed in a future release of the JDK.

To facilitate the transition, jdk.jsobject is now an upgradable module in the JDK. This means that the version of jdk.jsobject delivered with JavaFX can be used in place of the one in the JDK to avoid the compiler warning. This can be done as follows:

Applications using the SDK

When running with the JavaFX SDK, use the --upgrade-module-path argument. For example:

javac --upgrade-module-path=/path/to/javafx-sdk-24/lib
java --upgrade-module-path=/path/to/javafx-sdk-24/lib

NOTE: The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the --module-path option instead.

Applications using jlink to create a custom Java runtime image:

When creating your custom Java runtime image, put the JavaFX jmods on the module path ahead of the JDK jmods. For example:

jlink --output jdk-with-javafx \
    --module-path /path/to/javafx-jmods-24:/path/to/jdk-24/jmods \
    --add-modules ALL-MODULE-PATH

NOTE: The above will fail if you create a custom image using JDK 23 or earlier. JDK 24 is recommended with JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, put the JDK jmods ahead of the JavaFX jmods on the module path (that is, reverse the order of javafx-jmods-24 and jdk-24/jmods).

See JDK-8337280 for more information.

Java 26+

As of Java 26 you no longer have to mess around with --upgrade-module-path or, when using jlink, the order of JMODs on the --module-path because there's no longer a jdk.jsobject module in the JDK you need to replace—it's been removed. Which means now you just need to make sure the OpenJFX jdk.jsobject module is resolved as a named module just as you would with the "normal" JavaFX modules (or any other module).


JavaFX Maven Plugin

The JavaFX Maven Plugin seems to be relatively dead. As of this answer, the last release to Maven Central was in October 2021, the last commit to master was in January 2022, there are 76 open issues, and there are 8 open pull requests. Though there may be a fork out there that is more up-to-date. Or you could fork the plugin yourself.

The way this plugin works for non-modular applications is it places the JavaFX modules on the --module-path and ensures they're resolved via --add-modules. Everything else, including the project code, is paced on the class-path. Unfortunately, the plugin currently only does this for JavaFX modules whose names start with "javafx". The jdk.jsobject module's name does not start with "javafx", so it isn't added to the module-path. It's also not the only module affected by this problem; the jfx.incubator.* modules also don't end up on the module-path.

You can see this behavior in the source code of the plugin. You can also see the results in the debug output of javafx:run:

[DEBUG] Executable [...\jdk-26.0.1.8-hotspot\bin\java.exe]
[DEBUG] Total dependencyArtifacts: 13
[DEBUG] module descriptor path: null
[DEBUG] Classpath:3
[DEBUG]  ...\jfxapp\target\classes
[DEBUG]  ...\jdk-jsobject-26.0.1-win.jar
[DEBUG]  ...\jdk-jsobject-26.0.1.jar
[DEBUG] Modulepath: 10
[DEBUG]  ...\javafx-base-26.0.1-win.jar
[DEBUG]  ...\javafx-base-26.0.1.jar
[DEBUG]  ...\javafx-controls-26.0.1-win.jar
[DEBUG]  ...\javafx-controls-26.0.1.jar
[DEBUG]  ...\javafx-graphics-26.0.1-win.jar
[DEBUG]  ...\javafx-graphics-26.0.1.jar
[DEBUG]  ...\26.0.1\javafx-media-26.0.1-win.jar
[DEBUG]  ...\26.0.1\javafx-media-26.0.1.jar
[DEBUG]  ...\26.0.1\javafx-web-26.0.1-win.jar
[DEBUG]  ...\26.0.1\javafx-web-26.0.1.jar
[DEBUG] pathElements: 13
[DEBUG]  ...\jfxapp\target\classes :: null
[DEBUG]  ...\javafx-base-26.0.1-win.jar :: javafx.base
[DEBUG]  ...\javafx-base-26.0.1.jar :: javafx.baseEmpty
[DEBUG]  ...\javafx-controls-26.0.1-win.jar :: javafx.controls
[DEBUG]  ...\javafx-controls-26.0.1.jar :: javafx.controlsEmpty
[DEBUG]  ...\javafx-graphics-26.0.1-win.jar :: javafx.graphics
[DEBUG]  ...\javafx-graphics-26.0.1.jar :: javafx.graphicsEmpty
[DEBUG]  ...\javafx-media-26.0.1-win.jar :: javafx.media
[DEBUG]  ...\javafx-media-26.0.1.jar :: javafx.mediaEmpty
[DEBUG]  ...\javafx-web-26.0.1-win.jar :: javafx.web
[DEBUG]  ...\javafx-web-26.0.1.jar :: javafx.webEmpty
[DEBUG]  ...\jdk-jsobject-26.0.1-win.jar :: jdk.jsobject
[DEBUG]  ...\jdk-jsobject-26.0.1.jar :: jdk.jsobjectEmpty
[DEBUG] Executing command line: [...\jdk-26.0.1.8-hotspot\bin\java.exe, --module-path, ...\javafx-base-26.0.1-win.jar;...\javafx-base-26.0.1.jar;...javafx-controls-26.0.1-win.jar;...\javafx-controls-26.0.1.jar;...\javafx-graphics-26.0.1-win.jar;...\javafx-graphics-26.0.1.jar;...\javafx-media-26.0.1-win.jar;...\javafx-media-26.0.1.jar;...\javafx-web-26.0.1-win.jar;...\javafx-web-26.0.1.jar, --add-modules, javafx.base,javafx.controls,javafx.graphics,javafx.media,javafx.web, -classpath, ...\jfxapp\target\classes;...\jdk-jsobject-26.0.1-win.jar;...\jdk-jsobject-26.0.1.jar, com.example.jfxapp.Main]

Solution

There are a couple solutions, assuming the only issue is running the JavaFX application via Maven.

Use Exec Maven Plugin

Since you're using Java 26+, one option is to forgo the JavaFX Maven Plugin and use the Exec Maven Plugin instead. The configuration will be more manual but it'll work. For example, with the following:


  org.codehaus.mojo
  exec-maven-plugin
  ${exec-maven-plugin.version}

java

-p

--add-modules javafx.web --enable-native-access javafx.graphics,javafx.media,javafx.web -cp

${main.class}

You can now run your JavaFX application with:

mvn compile exec:exec

Continue to use JavaFX Maven Plugin

Manually add jdk.jsobject module to module-path

See the answer by Arne Bogaert for how this can be accomplished. Though be aware the jdk-jsobject artifact is published in the same was as the other JavaFX artifacts. That is:

  • An empty modular artifact is published with no classifier. The module name for this artifacts is xxxEmpty (e.g., javafx.graphicsEmpty).
  • A non-empty but platform-specific modular artifact is published with the classifier specifying the platform. The module name for this artifact is the expected one (e.g., javafx.graphics).

Which means you need to need to pass the jdk-jsobject--.jar JAR file for the --upgrade-module-path option, not just jdk-jsobject-.jar. Where is one of: linux, linux-aarch64, mac, mac-aarch64, or win. You may need to make use of profiles to pass the correct JAR depending on the host platform.

Note --upgrade-module-path is still needed here instead of --module-path, despite using Java 26+, because only the last --module-path option is used by Java. And JavaFX Maven Plugin passes its module-path after any user-configured options.

Place JavaFX on the class-path

You can configure JavaFX Maven Plugin to place everything on the class-path by setting runtimePathOption to CLASSPATH. This will cause JavaFX to be loaded into the unnamed module, which is technically an unsupported configuration. But the jdk.jsobject code will also be on the class-path and thus usable by the javafx.web code.

You will also need to have a separate launcher main class that is not a subtype of javafx.application.Application. For example:

import javafx.application.Application;

public class Launcher {

public static void main(String[] args) { Application.launch(YourAppClass.class, args); } }