JavaFx in oracle JDK 8 is same as openjfx 8 versions or not? what is the relationship between javafx in oracle jdk 8 and openjfx8?

Question

We are moving from Oracle jdk8 to OpenJDK 8. But our system has JavaFX code, which needs to migrate from JavaFX to OpenJFX.

I wonder what is the relationship between JavaFX in Oracle jdk8 and openjfx8. Can anyone explain for me?

Answer 1

Oracle unbundled and open-sourced JavaFX libraries

Oracle was bundling its own implementation of JavaFX with the Java 8 version of its Oracle JDK product.

Later, Oracle discontinued that bundle.

OpenJFX project

And around the same time, Oracle open-sourced its JavaFX implementation, making that source code a sub-project on the OpenJDK project. That sub-project is known as OpenJFX (as Oracle retains commercial rights to its “Java” branding). See its GitHub page, and its OpenJDK wiki page.

Oracle now shares leadership for OpenJFX development with the Gluon company. Gluon sells support, licenses for additional libraries, and services. Oracle may sell support as well.

OpenJFX is actively developed. A major release arrives around the same time as every major release of Java. Java 17 will released this month (2021-09), and OpenJFX 17 version is already available. JavaFX 17 requires JDK 11 or later. See Release Notes for JavaFX 17.

See the OpenJFX site for more info and developer documentation: https://openjfx.io/

Oracle JDK is built from OpenJDK

You said:

We are moving from oracle jdk8 to openjdk 8

The Oracle JDK product is based on OpenJDK. Oracle has committed to feature parity between them. The only differences are that (a) Oracle sells support for Oracle JDK and requires a fee when used in production (but not for development and testing), and (b) Oracle reserves the right to ship immediately any necessary fixes directly to its paying customers without waiting for the fix to wind its way through the OpenJDK process.

Options for deploying JavaFX/OpenJFX libraries

The current versions of Oracle JDK no longer bundle the JavaFX libraries. So no matter what distribution of Java you choose (Pivotal, Azul Systems, Microsoft, SAP, Amazon, BellSoft, Oracle, Red Hat/IBM, Adoptium/AdoptOpenJDK, etc.), you will need to address the issue of providing the necessary OpenJFX libraries.

One option is bundling the libraries with your app. The new jlink and jpackage tools might help.

• JEP 282: jlink: The Java Linker
• JEP 392: Packaging Tool

Another option is putting a copy of the OpenJFX libraries on the class path of your user’s machines.

A third option is using a JDK distribution that includes the OpenJFX libraries. At least two companies provide a variation of their JDK distributions that include OpenJFX: Azul Systems and BellSoft.

OpenJFX starts at version 11

You said:

But our system has javafx code, which needs migrate from javafx to openjfx?

I see only versions of OpenJFX numbered 11 through 18. Only OpenJFX 11 and 17 will have long-term support.

They recommend Java 16 for OpenJFX, with a minimum requirement of Java 11. So you may not be able to migrate your Java 8 based project to OpenJFX.

Suggestion: Migrate to versions 17

Java 17 is due this month, and is expected to be designated a long-term support (LTS) version. I suggest you consider updating your Java 8 app to Java 17 and OpenJFX 17. Both Java and JavaFX have evolved by leaps and bounds since versions 8.

First study the Answer by jewelsea discussing technical changes through the various versions of JavaFX & OpenJFX. Then carefully read through all the Release Notes for both product lines, keeping notes of any potential issues for your app. Then give it a try. Try converting, see what problems arise. Take a shot at fixing them. If you eventually succeed, you’ll be well placed for the future.

Resources

You may want to read these white papers:

• Java Client Roadmap Update by Oracle (2020-05)
• Java Is Still Free by Java Champions (2019-03)
• Oracle Java SE Support Roadmap by Oracle (2021-04)