<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Sep 27, 2025 at 11:59 PM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com">kevin.rushforth@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
This looks like quite an interesting project.<br>
<br>
<blockquote type="cite">
<div dir="auto">We are back to the great OpenJDK / JFX all-in-one
package as it was the case in jdk8 to 10 !</div>
</blockquote>
<br>
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.<br></div></blockquote><div><br></div><div>I agree, those artifacts need to be produced and they have to be similar to what we currently have with the gradle-based builds.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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.<br></div></blockquote><div><br></div><div>I think the difference between this project and what is currently possible using jlink is more than just convenience.</div><div>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. </div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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.<br></div></blockquote><div><br></div><div>Absolutely, that would be a great experiment. And I agree the required effort for the OpenJDK build procedures should ideally be zero. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
-- Kevin<br>
<br>
<br>
<div>On 9/27/2025 3:29 AM, Laurent Bourgès
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>Hi johan,</div>
<div dir="auto"><br>
</div>
<div dir="auto">We are back to the great OpenJDK / JFX
all-in-one package as it was the case in jdk8 to 10 !</div>
<div dir="auto"><br>
</div>
<div dir="auto">I love it,</div>
<div dir="auto">Let's go forward now!</div>
<div dir="auto"><br>
</div>
<div dir="auto">Cheers, </div>
<div dir="auto">Laurent</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le sam. 27 sept. 2025, 11:56,
Johan Vos <<a href="mailto:johan.vos@gluonhq.com" target="_blank">johan.vos@gluonhq.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi,
<div><br>
</div>
<div>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 <a href="https://github.com/openjdk-mobile/openjfx-build" rel="noreferrer" target="_blank">https://github.com/openjdk-mobile/openjfx-build</a>
. For questions about why this is done in the
openjdk-mobile organisation on github, see below.</div>
<div><br>
</div>
<div>The steps that are executed in the GhA are described in
the README.md at <a href="https://github.com/openjdk-mobile/openjfx-build" rel="noreferrer" target="_blank">https://github.com/openjdk-mobile/openjfx-build</a>
.</div>
<div>Basically, this boils down to</div>
<div>1. clone latest openjdk (or openjdk/mobile)</div>
<div>2. clone latest openjfx</div>
<div>3. apply a small patch to the openjdk repository (so
that it can deal with --with-openjfx-modules)</div>
<div>4. run the gradle tasks to generate shaderclasses (to
be removed)</div>
<div>5. configure and make the openjdk image.</div>
<div><br>
</div>
<div>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.</div>
<div>The value of the Github Actions, imho, is to easily
detect an issue with new code in either of the
repositories.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>There are many todo's left, including:</div>
<div>* make it work on windows, ios and android</div>
<div>* include media and webkit</div>
<div>* generate shaders using the OpenJDK code-generate
approach</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Johan</div>
<div><br>
</div>
<div>Q: Why is this in a repository that is part of the
openjdk-mobile initiative?</div>
<div>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.</div>
<div>Note that currently, we only have scripts to build
OpenJFX on OpenJDK for linux and mac (hence not yet for
mobile).</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>