The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
JavaFX 2 was generally supplied with the Java installation, not as a regular JavaFX 2 dependency in Maven Central. For a legacy application, the simplest workaround is to reference its local jfxrt.jar; for a shared build, install the matching runtime into a local or internal Maven repository. These are historical workarounds, not modern Maven best practice. If you are starting a project now, use OpenJFX instead.
Check which JavaFX and Java version the project expects
JavaFX 2.0, 2.1, and 2.2 are pre-modular releases with a different distribution model from modern OpenJFX. In the Oracle Java era, JavaFX 2.2 was bundled with Java SE 7 Update 6 and later Java 7 releases; JavaFX 2.2.5, for example, shipped with JDK 7u11. JavaFX 2.2 was also available as a standalone SDK for some Java 6 setups, particularly Windows. See Oracle’s supported configurations and JavaFX 2.2 installation guide.
Do not assume that a current JDK can run JavaFX 2. Use the JDK and JavaFX combination the application was built for. The archived JavaFX 2.2 system requirements vary by operating system: Windows, Mac OS X, and Linux had different Java prerequisites, and Linux also required GTK 2.18 or newer. Some features, including self-contained application packaging, required Java 7.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quickest legacy fix: reference the local JAR
First locate jfxrt.jar in the JavaFX-enabled JDK or standalone SDK. A JavaFX 2.2 installation commonly placed it under <JDK>/jre/lib/jfxrt.jar or <JavaFX-SDK>/rt/lib/jfxrt.jar, but the path depends on the distribution. Verify the file rather than assuming either path is universal. For a small project, copy the matching JAR into the project:
legacy-javafx-app/
├── lib/
│ └── jfxrt.jar
├── src/
│ └── main/java/
└── pom.xmlThen add this dependency to pom.xml:
<properties>
<java.version>1.7</java.version>
<maven.compiler.source>${java.version}</maven.compiler.source>
<maven.compiler.target>${java.version}</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>javafx</artifactId>
<version>2.2.3</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/jfxrt.jar</systemPath>
</dependency>
</dependencies>The coordinates com.oracle:javafx:2.2.3 here are labels for Maven’s dependency declaration; they do not make Maven download JavaFX 2.2.3. The actual dependency is the file named by systemPath. This local-file pattern appeared in historical community examples, including this JavaFX 2 Maven discussion.
Using ${project.basedir} is less machine-specific than writing an absolute path, but each checkout and build machine still needs the JAR at that location. The JAR must be supplied or provisioned separately. Maven’s system scope reads a specified local file; it is not a repository dependency and is not a good default for a portable team build.
Build and run a small test
Check which Java installation Maven actually uses:
mvn -versionCompare the reported Java home with the JavaFX-enabled JDK expected by the project. Then compile:
Rank #2
mvn clean compileA successful compile means the JavaFX classes are available to the compiler. For example, a minimal JavaFX 2 application can use these imports:
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.stage.Stage;
public final class HelloFx extends Application {
@Override
public void start(Stage stage) {
stage.setScene(new Scene(new Label("JavaFX is available"), 320, 120));
stage.setTitle("JavaFX test");
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}Compilation does not prove that the application can launch. Run it with the matching JavaFX-enabled JDK/JRE and test it on every target operating system. JavaFX 2 also had platform-specific runtime, graphics, media, and native-component requirements; see Oracle’s system requirements. Simply embedding jfxrt.jar in a shaded or executable JAR does not guarantee a portable application.
For a shared legacy build: install artifacts into Maven
A historical alternative used org.codeartisans.javafx:javafx-deployer-maven-plugin to inspect a local JavaFX installation and install generated artifacts into the local Maven repository. Its documented command was:
mvn org.codeartisans.javafx:javafx-deployer-maven-plugin:1.2:installThe generated runtime dependency could then be declared like this, using the version corresponding to the installed JavaFX runtime:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match<dependency>
<groupId>com.sun.javafx</groupId>
<artifactId>jfxrt</artifactId>
<version>2.2.1</version>
<scope>provided</scope>
</dependency>The plugin documentation describes this as a workaround because the JavaFX artifacts were not available from a public repository; it generated local artifacts such as com.sun.javafx:jfxrt from an existing installation. Read its documentation and treat it as legacy tooling: verify compatibility with the project’s JDK, Maven, operating system, and repository policy before relying on it. The generated artifact is local unless you deliberately publish it to an internal repository.
For a team-maintained application, an approved internal Maven repository is usually more reproducible than asking developers or CI machines to copy a JAR by hand. Confirm that you may store and distribute the relevant runtime, then publish the matching artifact internally. Document the required JavaFX and JDK versions as well.
Rank #4
Why Maven does not find JavaFX just because it is in the JDK
A JAR in a JDK installation is not automatically a Maven dependency. Maven resolves dependencies from configured repositories, its local repository, or explicit local-file declarations. An IDE may compile a project using a JavaFX-enabled JDK even while Maven reports that javafx.* packages do not exist. The two builds may be using different classpaths or Java installations; an archived Oracle forum discussion describes this distinction.
Maven scopes do not remove the need to make the artifact resolvable. provided means the dependency is needed to compile and is expected from the runtime environment; it does not tell Maven where to find an otherwise unavailable JAR. compile would make a normal resolved artifact available for compilation and runtime, but it does not turn a JDK-bundled library into a downloadable Maven artifact. Nor does declaring a dependency automatically package the JavaFX runtime for deployment.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Troubleshooting
package javafx.application does not exist
- Confirm that
lib/jfxrt.jarexists and is the expected JavaFX version. - Run
mvn -versionand check whether Maven uses the same JDK as the IDE. - Check that the
systemPathpoints to the file in the module containing thispom.xml. In a multi-module build, each module’s base directory may differ. - Confirm that the selected JDK or JavaFX SDK actually contains JavaFX 2; a modern JDK should not be assumed to include it.
Maven says the system path does not exist
Check the spelling and capitalization of jfxrt.jar, confirm that it is under the project directory containing the relevant POM, and verify the path from the module that declares the dependency. Do not rely on a developer’s separate JDK path if CI needs to build the project too.
Best Value
It compiles but fails to launch
Use the JavaFX runtime that matches the compile-time JAR and the application’s target environment. A compile-time classpath does not supply the runtime’s native or platform components. Test the actual launch and deployment path on the target operating system; do not infer success from mvn clean compile.
It works locally but fails in CI
CI will not have a developer’s JAR unless your build provisions it. Store an approved copy in an internal artifact repository, install it as a controlled build step, or provision the matching JDK/SDK explicitly. Avoid silently depending on whatever happens to be installed on a workstation.
For new projects, use OpenJFX instead
Modern JavaFX is distributed as OpenJFX modules with Maven artifacts under org.openjfx. It is not the JavaFX 2 runtime under new coordinates, and should not be substituted without checking JDK compatibility, API changes, module setup, and deployment needs. A modern project might declare modules like this, with a compatible version selected for its JDK:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors<properties>
<javafx.version>YOUR_COMPATIBLE_OPENJFX_VERSION</javafx.version>
</properties>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>${javafx.version}</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-fxml</artifactId>
<version>${javafx.version}</version>
</dependency>
</dependencies>OpenJFX artifacts, unlike the historical JavaFX 2 runtime arrangement, are available through Maven repositories; see the OpenJFX Maven artifact. Choose versions from current project requirements rather than assuming a JavaFX 2-era setup applies.
Quick Recap
Which approach should you choose?
- One-off legacy recovery: reference a verified
jfxrt.jarwithsystemPath, and record how to obtain the file and the required JDK. - Team-maintained JavaFX 2 build: use an approved internal artifact repository with a pinned, documented runtime; avoid relying on individual workstation installations.
- New development: use modern OpenJFX artifacts and validate the migration against the application’s JDK, APIs, and packaging requirements.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
