Building OpenJFX using the OpenJDK build system

[Johan Vos]

On Sat, Sep 27, 2025 at 11:59 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> This looks like quite an interesting project.
>
> We are back to the great OpenJDK / JFX all-in-one package as it was the
> case in jdk8 to 10 !
>
>
> This is largely independent of whether or not to include JavaFX modules
> directly in the JDK if it is to be adopted, although it could make it
> easier to do so. If this is to eventually replace the current gradle build
> system for desktop platforms, a requirement will be to produce exactly the
> same set of build artifacts as gradle does today. By default that means
> producing a set of JMODs, an SDK, and jars suitable for publishing to Maven
> central.
>

I agree, those artifacts need to be produced and they have to be similar to
what we currently have with the gradle-based builds.


> Optionally, it could support linking those modules into the JDK. I note
> that is already possible using jlink on the JMODs produce above, but it
> could be more convenient to have support for direct integration.
>

I think the difference between this project and what is currently possible
using jlink is more than just convenience.
When using jlink to create a JRE, there is no guarantee that the modules
are built in a consistent approach. Hence, it is possible to have the core
modules built against glibc 2.39 and the javafx modules built against glibc
2.35.
When building everything from the same build tools, we ensure that the
native libraries are very consistent with each other. It also makes
maintenance of OpenJFX easier, as we regularly update the minimum
requirements of some dependencies because they are updated in OpenJDK.

The additional jlink step that is currently needed if one wants to
distribute a JRE with JavaFX requires "unpacking" 2 projects, mixing some
artifacts, and repackaging it. While the tools do this is are really great,
it is still more plumbing work than the case where the `make images` is
used when compiling the JDK and where the JavaFX modules are immediately
part of the image.

Eventually, I might envision an effort that is independent of mobile,
> perhaps using a branch in the jdk-sandbox and jfx-sandbox for development.
> That would make it easy to ensure that the versions of JDK and JavaFX
> sources were compatible and allow experimenting with the boundary between
> what changes should go in the JDK (ideally nothing with direct knowledge of
> JavaFX) and what changes should go into JavaFX.
>

Absolutely, that would be a great experiment. And I agree the required
effort for the OpenJDK build procedures should ideally be zero.


>
> -- Kevin
>
>
> On 9/27/2025 3:29 AM, Laurent Bourgès wrote:
>
> Hi johan,
>
> We are back to the great OpenJDK / JFX all-in-one package as it was the
> case in jdk8 to 10 !
>
> I love it,
> Let's go forward now!
>
> Cheers,
> Laurent
>
>
> Le sam. 27 sept. 2025, 11:56, Johan Vos <johan.vos at gluonhq.com> a écrit :
>
>> Hi,
>>
>> As part of my efforts to build OpenJFX using the OpenJDK build system, I
>> created a script that exactly does this. The script is used in the Github
>> Action in the repository https://github.com/openjdk-mobile/openjfx-build
>> . For questions about why this is done in the openjdk-mobile organisation
>> on github, see below.
>>
>> The steps that are executed in the GhA are described in the README.md at
>> https://github.com/openjdk-mobile/openjfx-build .
>> Basically, this boils down to
>> 1. clone latest openjdk (or openjdk/mobile)
>> 2. clone latest openjfx
>> 3. apply a small patch to the openjdk repository (so that it can deal
>> with --with-openjfx-modules)
>> 4. run the gradle tasks to generate shaderclasses (to be removed)
>> 5. configure and make the openjdk image.
>>
>> We do have GhA scripts that can do the build on-demand, and they can be
>> modified to create daily/weekly/... builds. We do not recommend to use
>> these scripts for production. At least with Gluon, we do builds from a
>> Jenkins system where we have full control over the environment. This allows
>> us to use e.g. an ubuntu 24.04 system and deliver binaries that are working
>> on ubuntu 20.04, for example.
>> The value of the Github Actions, imho, is to easily detect an issue with
>> new code in either of the repositories.
>>
>> An important thing is that this is using the very latest openjdk and
>> openjfx code. As I said before: it is not hard to create builds of OpenJFX
>> using the OpenJDK for a very specific version, using (very specific)
>> patches. The hard thing is to do this without requiring a huge maintenance
>> effort.
>>
>> There are many todo's left, including:
>> * make it work on windows, ios and android
>> * include media and webkit
>> * generate shaders using the OpenJDK code-generate approach
>>
>> This is an open effort, so everyone is welcome to contribute. But also,
>> if others want to use a different approach, I'm all fine with that.
>>
>> - Johan
>>
>> Q: Why is this in a repository that is part of the openjdk-mobile
>> initiative?
>> A: JavaFX is an optional, but crucial part when running Java applications
>> on mobile. Since on mobile, it is even more critical to use the correct
>> compilers/tools/settings/flags than it is on desktop, it is really
>> beneficial to use a single build system for all components that have native
>> code. Hence, while building OpenJFX using the OpenJDK build system is very
>> useful for desktop platforms, it is almost a requirement when building for
>> mobile platforms.
>> Note that currently, we only have scripts to build OpenJFX on OpenJDK for
>> linux and mac (hence not yet for mobile).
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250928/875b5c2f/attachment.htm>