Quarkus Desktop brings AWT and Swing into the native-image era

Quarkus Desktop 0.1.0 takes on a difficult compatibility job: making Java's long-established AWT and Swing desktop stacks usable inside Quarkus applications, including as GraalVM native executables. The Quarkus project says the Quarkiverse extension supports JVM mode, dev mode and native builds on Windows, Linux and macOS.

What the extension supplies

Native compilation is awkward for AWT and Swing because the JDK resolves classes, resources and JNI callbacks by name, with different requirements on each platform. Quarkus Desktop registers the native-image metadata needed by AWT, Java2D, fonts, images, printing, clipboard operations, drag and drop, input methods, sound, accessibility and Swing. It also places the JDK libraries loaded by the executable beside the resulting binary, according to the project's launch post.

The extension is split between quarkus-desktop-awt and quarkus-desktop-swing. Version 0.1.0 is the dependency shown in the project's example. Applications can treat a window as a CDI bean: DesktopStartupEvent arrives on Swing's event dispatch thread after startup, while injection and Quarkus configuration work as they do for other beans. Closing the last window routes shutdown through Quarkus, allowing ShutdownEvent observers and @PreDestroy methods to run.

That lifecycle integration comes with a guardrail. Swing windows should use @Singleton or @Dependent; the extension rejects normal scopes such as @ApplicationScoped for Swing components because the CDI client proxy would create another component outside the event dispatch thread.

Threading and operating-system integration

For asynchronous work, Quarkus Desktop provides an EdtExecutor to move completion handlers back to Swing's event dispatch thread. The executor also works with Mutiny's emitOn and asynchronous CDI events. A @RunOnEdt annotation provides the reverse bridge for methods invoked by schedulers, REST resources or other non-EDT callers.

The integration extends to macOS application behavior. About, Preferences, Finder file-open actions and quit requests are exposed as CDI events; a quit observer can cancel shutdown when, for example, documents contain unsaved changes.

Platform limits still matter. Native builds target the platform on which they run. Linux uses system X11 libraries or XWayland; macOS requires Quarkus 4.0 and GraalVM 25.1 or later; and Windows arm64 remains JVM-only because the post says GraalVM has no native-image builder there. Native executables also cannot dynamically load classes that were unknown at build time.

The confidence test

The strongest evidence is the project's test approach rather than its API surface. Its showcase spans 75 pages and about 3,800 checks across graphics, text, images, Swing, look-and-feel variants, data transfer, printing, accessibility and sound. Continuous integration runs each page in JVM and native modes on Linux, Windows and macOS, then compares the results pixel by pixel and check by check. That does not erase the documented limits, but it gives maintainers a concrete baseline for deciding whether an existing Swing application is ready for a native-build experiment.