Quarkus Desktop compiles Swing and AWT apps to native executables
Victoria Shinder2 min readThe Quarkus team has introduced Quarkus Desktop, an extension for building AWT and Swing desktop applications with Quarkus, including as GraalVM native executables. A native build starts fast, needs no JVM on the user's machine and ships as one executable plus a few libraries, but AWT and Swing have been hard to compile natively because the JDK looks up classes, resources and JNI callbacks by name, differently on each platform.
The extension takes care of the registration a native image needs for the whole desktop stack, from AWT and Java2D through fonts, printing, the clipboard, drag and drop, sound and accessibility to Swing itself, and places the JDK libraries the program loads alongside the binary. One codebase then works in JVM mode, in Quarkus dev mode and as a native build on all three desktop platforms. There are two artifacts: quarkus-desktop-swing, and quarkus-desktop-awt for AWT-only applications.
The programming model follows Quarkus. A window is a CDI bean that observes DesktopStartupEvent, fired on the event dispatch thread; there is no main method. Windows must be @Singleton or @Dependent: a normal scope such as @ApplicationScoped would create a proxy outside the event dispatch thread, and the extension reports that mistake at build time. Slow work runs on a Quarkus executor and returns through EdtExecutor, and methods called from other threads can be annotated @RunOnEdt. On macOS, About, Preferences, Finder file opens and Cmd-Q arrive as CDI events.
Limits are documented: a native executable cannot load classes unknown at build time, macOS native builds need Quarkus 4.0 and GraalVM 25.1 or later, and Windows on arm64 runs in JVM mode because GraalVM has no native image builder there. The project's showcase has 75 pages and about 3,800 checks, compared pixel by pixel between JVM and native runs in CI.
Why it matters
Plenty of internal tools are still Swing applications, and shipping them has meant shipping a JVM. A single native executable with CDI and configuration makes those tools easier to distribute, as long as they avoid the dynamic class loading a native image cannot do.