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.
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.
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.
-- 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 <[email protected]> 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).
