Page History

...

Do you really want to build OpenJFX? We would like you to, but the latest stable build is already available on the JavaFX website, and JavaFX 8 is bundled by default in Oracle JDK 8 (9 and 10 also included JavaFX, but were superseded by 11, which does not). There are also some great community builds that may work for you.

Starting with Java 9, and the introduction of the module system, the JavaFX modules are now an integral part of the runtime environment for the desktop. Because of this tie, there is currently no provision or capability for the output of the OpenJFX 9 or later build to be used as an overlay. It is still possible however to develop and enhance OpenJFX, and use that result to build an OpenJDK. (still relevant?)

We are exploring making this easier, by enabling a developer to build a set of javafx.* modules that can be used with a clean OpenJDK build (without the javafx.* modules). Stay tuned.

...

You will need Windows 10 or later (Windows 10 is recommended) 64-bit OS.

You need to have the following tools installed:

• Cygwin. Some packages to make sure are installed are:
  
  • openssh
  • zip
  • unzip
  • make (needed to compile media)
  • makedepend (needed for media)
  • Optional: git
• Microsoft Visual Studio 2022. You can use the Enterprise, either Professional, or Community edition or the command line BuildTools. The Desktop development with C++ workload is required at most, but it may be possible to install individual components to satisfy the requirements.

...

All commands on this page are ran run inside Cygwin (and not in Windows CMD).

You will likely The JavaFX build will automatically locate your Visual Studio installation, as long as you installed it in the default location. You no longer need to set the following any env variables to point to your VS 2019 2022 installation, since Microsoft no longer sets such variables. This presumes that:

• You installed JDK N in C:\Program Files\Java\jdk-N where N is the JDK version.
• You installed the Community edition of Visual Studio 2019 in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community. If this isn't set correctly, you might see an error during the build saying that vcvars32.bat is missing.

You should adjust these as needed for your system.

export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build"
export JAVA_HOME="C:/Program Files/Java/jdk-N"

Note the use of the double backslash in the VS150COMNTOOLS env var. This is needed because the cygwin shell uses the '\' as an escape character. With JAVA_HOME it is easier to just set it using forward slashes (although backslashes are fine as long as you escape them).

If these definitions aren't persisted between launches of Cygwin, you can either set them in the Windows Environment Variables UI or in the /home/$user$/.bash_profile file (these are ran on startup). Use export -p to verify that the env variables are set correctly.

Missing paths issue

The initial build process that generates the needed resources is done by the \buildSrc folder. On Windows, it tries to locate all the needed tools and write their paths to the \build\windows_tools.properties file. Sometimes it fails and the file is left blank, which results in various path-not-found errors, e.g., on WINSDK_DIR. This means that you will have to define these paths manually. For your convenience, here is a ready file from Win10 with VS2019 Community edition. You will need to correct the user name and possibly the version numbers, but it should give an idea of what the build looks for:

...

...

unless you installed Visual Studio in a non-standard location, for example, the D: drive instead of the default C: drive.

Missing paths issue

The initial build process that generates the needed resources is done by the buildSrc folder. On Windows, it tries to locate all the needed tools and write their paths to the build\windows_tools.properties file. If it fails, the file is left blank, which results in a fatal error. In this case, define the VSCOMNTOOLS variable (older versions of JavaFX used VS150COMNTOOLS) to point to the VC\Auxiliary\Build directory in your Visual studio Installation. For example, use the following if you installed Visual Studio 2022 on the D: drive.

export VSCOMNTOOLS="D:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Auxiliary\\Build"

Note the use of the double backslash in the VSCOMNTOOLS env var. This is needed because the cygwin shell uses the '\' as an escape character.

If these definitions aren't persisted between launches of Cygwin, you can either set them in the Windows Environment Variables UI or in the /home/$user$/.bash_profile file (these are ran on startup). Use export -p to verify that the env variables are set correctly.

Mac

You will need macOS 12 (Monterey) or later.

...

If you build WebKit (it is not built by default) you will need the following additional tools:

• Cmake 3.1322.3 or later, available from the Cmake download site
• bison
• flex
• gperf

• perl (5.10 or later)

• python3

• ruby (2.5 or later)

The following should satisfy the requirements (but check the version of cmake) :

...

OpenJFX N is formally compatible with JDK N and N-1. For OpenJFX 1322, download OpenJDK 12 21 or later to use as the boot JDK to build and test OpenJFX. We recommend to use the latest version, however, Gradle might not support that version, so a version that Gradle supports might also be required to run Gradle itself (though it will use the latest version of the JDK through toolchain support).

...

Gradle then tells us what the default tasks are. In this case, our default task is the 'sdk' task. This is the task that will be executed if you just call 'gradle' alone without providing any additional arguments. After this comes a listing of different tasks, broken out by group. The first group is the "Basic" group which contains the tasks you may find yourself using most often. These are all named and have a description provided. For example, if I wanted to execute executing the 'clean' task , then I would do so would be done like this:

$ sh gradlew clean

Finally, the tasks task gives us a useful hint that we can pass the --all argument in order to see all of the tasks in more detail. This produces a lot more output, but really gives an in depth look at what tasks are available for you to call.

I As mentioned above that our , the root project is called "rt", and that we have sub-projects in the gradle build. To see all of the projects available to you, execute the the projects task (which you will notice was in the "Help tasks" group produced by the tasks task). This lists not just what projects are available, but what their name is, and what the project hierarchy is.

...