Hi John, Many thanks for the feedback and the confirmation, much appreciated! As for the question "when can we switch?" -> aha, great question. I believe the major todo is to make sure that this approach is maintainable, without putting a burden on the openjkd/jdk development, making sure it does not make the life of the current openjfx developers/reviewers more difficult. So we first need to make sure the approach is maintainable in a predictable and consistent way. This is what I just mentioned in my reply to Phil on the same thread [1], and I discuss it at greater length in a separate post [2]. I want to add specifically in this reply that I believe that this suggestion (the auto-updated leverage of a slightly extended jdk-build approach) brings us also a step closer to completely reproducible builds.
- Johan [1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/053076.html [2] https://johanvos.wordpress.com/2025/03/27/building-a-jdk-including-openjfx-part-2/ On Wed, Mar 12, 2025 at 8:11 PM John Neffenger <j...@status6.com> wrote: > On 2/27/25 7:15 AM, Johan Vos wrote: > > The POC I have for this (linux-only at the moment) is at > > https://github.com/johanvos/jdk/tree/jfxpoc-blog > > That's very clever, Johan. I never thought of using the JDK repository > as-is to build JavaFX. I agree it's "one of the most excellent build > systems for software development today," so what a great idea to start > with that! > > Your "proof of concept" repository builds successfully for me on Ubuntu > 22.04 LTS and goes rather smoothly through the JavaFX modules: > > Compiling up to 1 files for java.se > -> Compiling up to 312 files for javafx.base > Compiling up to 18 files for jdk.accessibility > Compiling up to 3 files for jdk.editpad > Compiling up to 904 files for jdk.hotspot.agent > Compiling up to 64 files for jdk.jconsole > Compiling up to 69 files for jdk.jpackage > Compiling up to 8 files for jdk.unsupported.desktop > -> Compiling up to 1695 files for javafx.graphics > -> Compiling up to 296 files for javafx.controls > > The only rough edges are the 'javac' notes about deprecated APIs and > unchecked or unsafe operations in use by JavaFX. Also, as you note, the > 'gcc' warnings are a bit jarring when you're accustomed to the sparse > output of the JDK build by itself. > > After the build, the JavaFX JMOD files are found in the right place: > > $ ls build/linux-x86_64-server-release/images/jdk/jmods/javafx* > build/linux-x86_64-server-release/images/jdk/jmods/javafx.base.jmod > build/linux-x86_64-server-release/images/jdk/jmods/javafx.controls.jmod > build/linux-x86_64-server-release/images/jdk/jmods/javafx.graphics.jmod > > and the runtime image includes over 4,000 JavaFX classes: > > $ jimage list build/linux-x86_64-server-release/images/jdk/lib/modules \ > | grep javafx | wc -l > 4009 > > I tested it with a "Hello World" JavaFX application on Ubuntu 24.04 LTS, > and it worked fine except for a minor error: > > $ opt/jdk/bin/java --enable-native-access=javafx.graphics \ > -jar tmp/dist/hello-javafx-1.0.0.jar > Mar 12, 2025 7:04:06 PM com.sun.javafx.css.StyleManager loadStylesheet > WARNING: Resource "com/sun/javafx/scene/control/skin/modena/modena.css" > not found. > Hello World! > > So when can we switch?! :-) > > Thanks, > John > >
