live wire
▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security
upstreambeat.ai
guideJAVA

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

The new Quarkiverse extension packages decades-old Java desktop APIs for Quarkus dev mode and GraalVM native executables across three operating systems.

Quarkus Desktop coverage and platform-support chart
Chart: figures from the story
By The News Desk· Oct 1, 2026the quick take — two AI hosts go live when you do

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.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk