Port AWT Extension to MacOS

[holly-cummins]

Describe the bug

I'm raising this more in hope than expectation, because I know ...

Although GraalVM doesn't support AWT, Liberica NIK does, from about v23 on. But the Quarkus AWT extension still doesn't work, even on Liberica.

This is related to #30908 (where @Karm got the app working on Linux, but the attempt to get it working on mac was abandoned). It's also related to #48422.

I have, of course, experimented with various combinations of marking classes and packages as build time or run time, but I can't find an 'end' to the chain; every addition just drags more things into the wrong side. I assume @Karm wouldn't have any more luck than me, but maybe he will (after all, we can make it work on Linux).

Expected behavior

In principle, if the VM works with AWT, it should work with our AWT extension.

Actual behavior

Fatal error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: An object of type 'javax.swing.plaf.ColorUIResource' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

How to Reproduce?

1. Patch the quarkus AWTProcessor to comment out the line which flags MacOS as unsupported (search for MacOS AWT integration is not ready in Quarkus, or comment out lines 56-58. The statement is true for GraalVM, but not for Liberica NIK. Rebuild the extension.

2. Switch to using Liberica NIK

sdk use java 25.r25-nik  

3. Download an empty application from code.quarkus.io

4. Update the pom to include awt:

        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-awt</artifactId>
            <version>999-SNAPSHOT</version>
        </dependency>

5. Build with mvn package -Pnative. The build will fail in the analysis step.

Output of uname -a or ver

Darwin hcummins-mac 24.6.0 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041 arm64

Output of java -version

openjdk version "25" 2025-09-16 LTS OpenJDK Runtime Environment Liberica-NIK-25.0.0-1 (build 25+37-LTS) OpenJDK 64-Bit Server VM Liberica-NIK-25.0.0-1 (build 25+37-LTS, mixed mode, sharing)

[Eng-Fouad]

What is the output if you include the option --trace-class-initialization=javax.swing.plaf.ColorUIResource?

[holly-cummins]

What is the output if you include the option --trace-class-initialization=javax.swing.plaf.ColorUIResource?

I did do that tracing, and added the named class to runtime classes (it might have been java.awt.Color?), but that then caused more classes to be dragged into runtime, and after a few hours, I gave up trying to find a division between runtime and build-time that worked. Having said that, I think the solution will be to repeat that effort but actually succeed in finding the division – but I'm hoping someone else has the knack of it more than me!

This was one of the configurations I tried (there were lots):

quarkus.native.additional-build-args=--trace-object-instantiation=java.awt.Color
quarkus.native.additional-build-args-append=--initialize-at-run-time=javax.swing.text.html.HTMLEditorKit\\,sun.datatransfer.DataFlavorUtil$DefaultDesktopDatatransferService\\,sun.swing.SwingUtilities2\\,javax.swing.text.html.HiddenTagView\\,sun.lwawt.LWWindowPeer

[holly-cummins]

If anyone else hits this, I ended up working around it by just using a container as a facade:

podman run -it --rm --entrypoint /bin/bash -v `pwd`:/project:z -v ~/.m2:/maven:z quay.io/quarkus/ubi9-quarkus-mandrel-builder-image:jdk-21

I didn't have any luck with the GraalVM Community docker images (core dumps when compiling), but Mandrel worked first time. Go team-Mandrel!

[Karm]

@holly-cummins It's not complicated, I'd day, it's just annoyingly laborious and version dependent :-D
The process that let me here https://github.com/quarkusio/quarkus/blob/main/extensions/awt/deployment/src/main/java/io/quarkus/awt/deployment/AwtProcessor.java was stepping JDK in debugger, partially Java, partially gdb, some printf debugging and browsing AWT source code. The accompanying test suite is designed with malformed and malevolent images in mind, so as also the code paths where C code creates and exception in Java code are covered. It's less of a whack-a-mole than trying to cater to GraalVM logs. Native agent also helped.

The reason why MacOS is unsupported:
https://github.com/quarkusio/quarkus/blob/main/extensions/awt/deployment/src/main/java/io/quarkus/awt/deployment/AwtProcessor.java#L57
is that nobody did the same flow for MacOS. The code path initialization differs, especially at the beginning.
Windows: same story:
https://github.com/quarkusio/quarkus/blob/main/extensions/awt/deployment/src/main/java/io/quarkus/awt/deployment/AwtProcessor.java#L54

Mind that the thing has to be robust and passing the test suite. One could take down the server just by e.g. sending an unexpected image compression. The test suite goes into great lengths to literally enumerate variants: https://github.com/quarkusio/quarkus/blob/main/integration-tests/awt/src/test/resources/encoders_test_config.txt

TL;DR:
I'll be glad to help and work on the MacOS integration (aarch64 only though). It just seemed there was no demand since everyone was just running it in a Linux container anyway.

[quarkus-bot]

/cc @galderz (awt)