Building OpenJFX with the JDK build system

[Johan Vos]

Hi Phil,

Thanks for your reply. I agree that the webkit build should be very doable,
as it is in fact simply invoking make to an external project.
I am slightly more worried about the generation of the shader code, and the
use of antlr for this. I'd like to use the gensrc phase of the jdk for
this, but I'm a bit stuck on using that with external dependencies.

My main work over the past weeks has been in finding a "balanced" approach
for maintaining the OpenJFX code and the build instructions.
I wrote a second post about this, with a proposal:
https://johanvos.wordpress.com/2025/03/27/building-a-jdk-including-openjfx-part-2/

My first efforts were to check if it would be feasible to build OpenJFX
with the OpenJDK build system, and my focus then shifted to how
maintainable it can be.
For very good reasons, the impact of whatever we do/require in OpenJFX on
the JDK build team/infrastructure should be very minimal. I explored a
number of options, and my current suggested approach is to (for now) keep
the OpenJFX sources in the openjdk/jfx repository, and having the
build/make logic in a skara-synced fork of openjdk/jdk. I added a
`--with-openjfx-modules` option to configure for this.

The TLDR of this is: the OpenJFX code stays in the openjfx repo, and the
configure/make logic goes into an auto-synced jdk-fork.

While this second step has nothing to do with the code, and even the
building itself, I believe it is really important to get it right. Being
able to distribute different versions of JavaFX for different platforms,
making them work with well-defined versions of the JDK is key to the
success and adoption of JavaFX, and it has a considerable influence on the
cost of maintaining (and distributing) JavaFX.

That is why my suggested approach separates the (semantic/repository)
location of code and build logic. It is not enough to use the existing
OpenJDK build logic (including toolchain with matching compiler/lib
versions); we also need to be able to auto-update to changes in this build
logic, versions, compilers, libraries...

I am very much looking forward to opinions about this.

- Johan


On Tue, Mar 11, 2025 at 9:01 PM Philip Race <philip.race at oracle.com> wrote:

> I see no one has responded. That isn't because of a lack of interest ..
> we just haven't had time to discuss it.
>
> Undoubtedly a lot of details to figure out but my take is this is worth
> pursuing.
>
> For webkit, I'd like to think it is *possible* to build it using the JDK
> build system, at least
> used as a bootstrap for the cmake webkit build, and at the end to
> collect the artifacts.
>
> A "clean up compiler warnings" effort would be valuable on its own.
> Until we actually transitioned the build, we'd probably have to add to
> the gradle system
> a way to disable specific warnings, like the JDK does, because it isn't
> practical to eliminate all warnings,
> since they some times come from a 3rd party library.
>
> -phil.
>
>
> On 2/27/25 7:15 AM, Johan Vos wrote:
> > Hi,
> >
> > I introduced this topic during the OpenJDK Committers' workshop in
> > Brussels, on Feb 3, 2025.
> > For a long time, I was thinking about building OpenJFX using the JDK
> > buildsystem, and I just blogged about a very basic and limited POC for
> > doing so on Linux:
> > https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/
> > . The POC I have for this (linux-only at the moment) is at
> > https://github.com/johanvos/jdk/tree/jfxpoc-blog
> > This is just a personal idea and effort, but I would be more than
> > happy to discuss how we as the OpenJFX developers might benefit from
> this.
> >
> > One of the main reasons for doing this (I list a number of reasons in
> > my blog post), is the cross-compilation capability. It is also very
> > convenient that the result of the build is now a full JDK image,
> > including the JavaFX modules. I am aware that some companies
> > distribute JavaFX modules with their JDK distribution, and this might
> > help a better alignment.
> >
> > Since I am also the OpenJDK/Mobile project lead, I have to work with
> > the JDK build system anyhow. To me personally, it saves a major amount
> > of time if I only have to use 1 build system (configure/make) instead
> > of 2 build systems. This is no criticism at all to Gradle, but I lack
> > the expertise (and time to learn) needed to work efficiently with it.
> > With all the projects I do, I try to be as efficient as possible with
> > my time, and streamlining build systems helps.
> > The JDK build system is really excellent, and since it is used by so
> > many OpenJDK developers, it feels very familiar. The delta that is
> > needed to have it working and support for JavaFX is very small.
> >
> > The POC I did is far from complete. There are a number of issues that
> > need to be tackled, e.g.:
> > * what about webkit?
> > * we have a code-generator for shaders, that is using a very old
> > external dependency. While the JDK build system has great support to
> > generate code, I'm not sure this is the ideal approach
> > * warnings, warnings and warnings.
> >
> > The last item is something that I believe should be tacklked in any
> > case. I had to disable the warnings-as-errors, and I had to add a fair
> > amount of exceptions to javac warnings. This might be a good time to
> > look into this as well.
> >
> > Again, I want to stress that this is just an experiment I did because
> > it would save me lots of time, and make it much easier for me to
> > understand what is going on in builds. I absolutely do not want to
> > imply that this is much better than what we currently have. But maybe
> > others are interested as well, and in that case we can discuss this.
> >
> > - Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250328/a8007bd7/attachment-0001.htm>