Quarkus Desktop kompiliert Swing- und AWT-Apps zu nativen Programmen
Victoria Shinder2 Min. LesezeitDas Quarkus-Team hat Quarkus Desktop vorgestellt, eine Erweiterung für AWT- und Swing-Desktopanwendungen mit Quarkus, auch als native GraalVM-Programme. Ein nativer Build startet schnell, braucht auf dem Rechner keine JVM und wird als eine Datei mit wenigen Bibliotheken ausgeliefert. AWT und Swing ließen sich bisher aber schwer nativ kompilieren, weil das JDK Klassen, Ressourcen und JNI-Callbacks über Namen sucht, auf jeder Plattform anders.
Die Erweiterung registriert, was AWT, Java2D, Schriften, Bilder, Druck, Zwischenablage, Drag and Drop, Eingabemethoden, Sound, Barrierefreiheit und Swing in einem nativen Image brauchen, und kopiert die vom Programm geladenen JDK-Bibliotheken daneben. Dieselbe Anwendung läuft im JVM-Modus, im Dev-Modus und nativ unter Windows, Linux und macOS. Es gibt zwei Artefakte: quarkus-desktop-swing und quarkus-desktop-awt für reine AWT-Anwendungen.
Das Programmiermodell folgt Quarkus. Ein Fenster ist eine CDI-Bean, die DesktopStartupEvent beobachtet, das auf dem Event-Dispatch-Thread ausgelöst wird; eine main-Methode gibt es nicht. Fenster müssen @Singleton oder @Dependent sein: Ein normaler Scope wie @ApplicationScoped würde einen Proxy außerhalb des Event-Dispatch-Threads erzeugen, und die Erweiterung meldet diesen Fehler beim Build. Langsame Arbeit läuft auf einem Quarkus-Executor und kehrt über EdtExecutor zurück, Methoden, die von anderen Threads aufgerufen werden, lassen sich mit @RunOnEdt markieren. Unter macOS kommen About, Einstellungen, aus dem Finder geöffnete Dateien und Cmd-Q als CDI-Ereignisse an.
Grenzen sind dokumentiert: Ein natives Programm kann keine zur Build-Zeit unbekannten Klassen laden, native macOS-Builds brauchen Quarkus 4.0 und GraalVM 25.1 oder neuer, und Windows auf arm64 läuft im JVM-Modus, weil GraalVM dort keinen Native-Image-Builder hat. Die Showcase-Anwendung hat 75 Seiten mit rund 3800 Prüfungen, die in der CI Pixel für Pixel zwischen JVM- und nativen Läufen verglichen werden.
Warum das wichtig ist
Viele interne Werkzeuge sind noch Swing-Anwendungen, und sie auszuliefern hieß bisher, eine JVM mitzuliefern. Ein einzelnes natives Programm mit CDI und Konfiguration macht diese Werkzeuge leichter verteilbar, solange sie auf dynamisches Klassenladen verzichten, das ein natives Image nicht kann.