Viele Demos von GraalVM native-image mit Spring Boot verwenden ein überschaubares Feature-Set oder sind sogar nur auf der Ebene einer Hello-World Anwendung.
In Zusammenarbeit mit einem Kunden konnten wir ein Projekt mit Spring Boot und Spring Native für den produktiven Einsatz entwickeln. Da die Vorteile von Spring Native nicht zwingend gebraucht wurden, gab es stets die Option, klassisches Spring Boot als Fallback zu nutzen, sollten die fachlichen Anforderungen an technische Grenzen von Spring Native stoßen.
Das war zum Glück nicht der Fall.

Die Anwendung befindet sich inzwischen im produktiven Einsatz und es konnten auch im längeren Betrieb mit wechselnder Last keine Probleme festgestellt werden, die durch Spring Native bzw. Substrate VM zur Laufzeit zurückzuführen wären.

Folgende Technologien wurden in der Anwendung verwendet:

Damit ergibt sich schon ein recht umfangreicher und repräsentativer Stack. Die Auslieferung und der spätere Betrieb erfolgt als Docker Image, die finale Größe ist mit komprimierter Anwendung ca. 74 MB, die Startzeit ist relativ langsam mit ca. 1 Sekunde inkl. Tomcat. Der dominierende Anteil scheint Spring Security zu sein, dies wurde jedoch nicht eingehend untersucht.
Für das Projektsetup wurde https://start.spring.io/ verwendet, hier wurde "Spring native [experimental]" als Abhängigkeit gewählt. Dadurch wurden die wichtigsten Einstellungen in der pom.xml bereits vorgenommen, um ein GraalVM native-image Artefakt zu erzeugen.

Während der Entwicklung wurden Spring Native 0.10 und 0.11 veröffentlicht. Die Anpassungen an die neueren Versionen waren relativ schnell erledigt, jedoch musste nach den z.T. neu auftretenden Fehlern erst rechechiert werden. Für ein Projekt im Beta-Stadium ist das jedoch akzeptabel.

Bei Verwendung des GraalVM native-image wird das sogenannte closed-world Prinzip angewendet. Damit ist gemeint, dass nicht zur Laufzeit neue Klassen hinzukommen dürfen, die dann dynamisch geladen werden.
Reflection ist ebenfalls ein nicht mehr vollumfänglich zur Verfügung stehender Aspekt, denn dazu wird normalerweise die Dynamik der JVM genutzt. Als Alternative kann das zwar durch die Substrate VM emuliert werden, doch die dazu nötigen Metadaten machen den Build langsamer und vor allem die Anwendung auch größer. Daher sollten Anwendungen und Libraries, die für das GraalVM native-image optimiert werden, auf Reflection soweit wie möglich verzichten.

Spring bringt seit Spring Native 0.11 ebenfalls einen AoT Modus mit. In einem zusätzlichen Build-Schritt sollen so z.B. Spring Beans frühzeitig analysiert, initialisiert und miteinander verbunden werden. Damit wird die Startupzeit zum einen verbessert, zum anderen wird weniger Reflection Code benötigt.
Weiterhin werden Konfigurationen zur Steuerung des GraalVM native-image Compilers erzeugt. So können zum Beispiel JDK-Proxies erzeugt werden, die unter anderem für Spring AoP benötigt werden.

Das ganze kommt jedoch mit einer für Spring Entwickler ggf. sehr überraschenden Eigenschaft: Da bereits zur Buildzeit die Anwendung initialisiert wird, wird die Konfiguration deutlich statischer.
Ist man es sonst gewohnt, z.B. durch Properties oder Profile zwischen verschiedenen Konfigurationen der Anwendung zu wechseln, wird dies nun zur Buildzeit fixiert. Evtl. soll sich dies noch ändern, aktuell entscheidet sich jedoch zur Buildzeit, welche Beans registriert werden, und wie diese initialisiert werden.

Eine dynamische Steuerung von Loglevel und auch die Belegung von ConfigurationProperty Klassen ist jedoch möglich.

Spring native bringt die Möglichkeit mit, über Java-Annotationen die für die Steuerung des GraalVM native-image Schritts genutzten Konfigurationsdatein zu erzeugen. Das ist typsicherer und mit Code-Completion einfacher, als in JSON-Dateien zu arbeiten.

Die Hints können an beliebigen Klassen, die als @Configuration markiert sind, angegeben werden. Typische Verwendung finden die Hints in diesen Fällen:

Als Entwickler vergisst man oft, an wie vielen Stellen Reflection zum Einsatz kommt. Schon bei einfachen Dingen, wie Spring WebMVC Model-Objekten, die mit der Thymeleaf Template-Engine verwendet werden, führten zu Programmfehlern.
Abhilfe schaffen hier entsprechend Hints: @TypeHint(types = LineQuery.class) sorgt für die Berücksichtigung durch GraalVM _ native-image_. Auch @ConfigurationProperty Ziele müssen mitunter entsprechend annotiert sein. Zum Teil erkennt das Spring AoT Maven Plugin die Klassen bereits und erzeugt die Hints selbstständig. Auch für die Serialisierung von/zu JSON mit Jackson müssen die Klassen entsprechend markiert werden.

Überraschungen kann man auch an anderer Stelle erleben: Selbst die Konfiguration der JPA Naming-Strategie benötigt einen entsprechenden @TypeHint(typeNames = "org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl").
Verwendet man @EnableJpaAuditing müssen die zu verwendenden Listener und Annotationen aufgeführt werden. Hier bleibt zu hoffen, dass Spring AoT dies zukünftig selbstständig erkennen kann, und auf @TypeHint(types = AuditingEntityListener.class) sowie @TypeHint(types = CreatedDate.class) verzichtet werden kann.
Verwendet man das RestTemplate mit der JDK HTTP-Implementierung ist auch dazu ein Hint erforderlich @TypeHint(types = org.springframework.http.client.SimpleClientHttpRequestFactory.class).

Bei der Verwendung von Native-Queries im Spring Data JPA Umfeld wird ein Proxy-Hint benötigt: @JdkProxyHint(types = {NativeQueryImplementor.class, QueryImplementor.class})

Für die mit @EnableAsync aktivierte @Async-Annotation wird Spring AoP mit entsprechenden Proxies verwendet. Leider war auch dazu ein Hint erforderlich: @AotProxyHint(targetClass=MailNotifier.class, proxyFeatures = ProxyBits.IS_STATIC), auch hier bleibt zu hoffen, dass eine automatische Generierung möglich ist.

Eine Alternative dazu, dass der Entwickler entsprechende Angaben machen muss, stellt der Tracing Agent dar. Ist er aktiviert, zeichnet er auf, wie die Anwendung sich verhält und generiert daraus die entsprechende Konfiguration. Hier zahlt sich aus, wenn es eine Testautomatisierung gibt, die die Anwendung einmal durch alle wichtigen Zustände führt.

Wie bereits erwähnt ist aktuell eine große Einschränkung, dass die Anwendung nicht flexibel für unterschiedliche Ausprägungen konfiguriert werden kann. Das gilt für Autoconfigurations gleichermaßen, wie für Java Config in der programmatisch Beans in Abhängigkeit von bestimmten Umgebungszuständen registriert werden oder @Profile Beans.

Mehr Informationen dazu liefert die Dokumentation: https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#support-spring-boot

Es ist wichtig zu verstehen, dass eine Anwendung als GraalVM native-image sich anders verhält, als die selbe Codebasis in HotSpot. Es ist daher unerläßlich entsprechende Tests auch im native Modus auszuführen. Mit Spring Native 0.11 ist dafür Unterstützung für Junit 5 bereitgestellt worden. Mockito wird allerdings derzeit nicht unterstützt.

In der Praxis erscheinen auch vor allem Integrationstests relevant, die das Zusammenspiel der verschiedenen Komponenten und möglicherweise sogar Umsysteme testen, als Komponententests.

Flyway ist neben Liquibase ein häufig verwendetes Werkzeug zur Verwaltung von Datenbankmigrationen. Ist die Abhängigkeit aktiviert, so crasht aktuell eine Spring Native Anwendung beim Start mit einer Nullpointer Exception.
Abhilfe lässt sich - wieder einmal - durch einen Hint schaffen: @ResourceHint(patterns = "org/flywaydb/core/internal/version.txt").

Allerdings verwendet Flyway, um nach den zu verwendenden Migrationen zu suchen, ein Verfahren, dass nicht mit der Substrate VM-Laufzeit kompatibel ist. Somit stürzt die Anwendung nicht direkt ab, jedoch werden die Datenbankmigrationen nicht gefunden und damit auch nicht ausgeführt.

Hier bleibt aktuell lediglich die separate Ausführung der Migrationen - z.B. durch das Flyway Maven Plugin.
Um sicher zu gehen, dass die Datenstrukturen zu den JPA Entities passen, kann durch spring.jpa.hibernate.ddl-auto=validate eine Validierung durch Hibernate aktiviert werden. Auch wenn dies keine komplette Sicherheit liefert, hat sich dies bereits bewährt, um schnelles Feedback zu erhalten, ob ggf. Migrationen fehlen.

Das zugehörige Ticket für Flyway mit Spring native ist https://github.com/flyway/flyway/issues/2927

WebJARs stellen Artefakte für den Browser zur Verwendung mit Maven oder Gradle zur Verfügung. Das sind in der Regel CSS und JavaScript Ressourcen, die durch den Browser nachgeladen werden. Spring Boot unterstützt die Auflösung der angefragten Ressourcen auf JAR Archive, im Kontext von native-image funktioniert das jedoch nicht.
Das Problem ist vermutlich vergleichbar mit dem bei Flyway. Abhilfe schafft dabei ein eigener AbstractResourceResolver, der in Spring WebMVC konfiguriert wird.

Gerade zur Entwicklung serverseitiger Anwendungen mit Thymeleaf ist der live-reload durch die Spring Boot Devtools extrem praktisch.
Um die Abhängigkeit lediglich zur Entwicklungszeit zu aktivieren, wurde mit einem separaten Maven-Profil local gearbeitet, dass die Abhängigkeit enthält.

Für den Build mit Maven kann sehr gut ein Build-Container mit Docker eingesetzt werden. Auf diese Weise kann ein Setup von GraalVM und dem native-image Tool und sogar einer JVM auf dem Buildsystem vermieden werden.
Spring bietet dazu eine Integration mit den Paketo Builder-Images an. Eine entsprechende Konfiguration kann im Abschnitt zum spring-boot-maven-plugin vorgenommen werden.

Der Ressourcenbedarf im Build ist nicht unerheblich: Für die betrachtete Anwendung werden auf einem Notebook alle Kerne gut ausgelastet, gut 12 GB RAM belegt und der Build dauert inkl. Erzeugung von Dokumentation und Docker Image ca. 9 Minuten.

Durch Tomcat und den relativ umfangreichen Einsatz von weiteren Technologien wird das finale Docker-Image mit 212 MB relativ groß. Die gemessene Startzeit auf dem selben Notebook beträgt ca. 1.5 Sekunden.

Die Imagegröße läßt sich noch weiter optimieren: Das nativ übersetzte Programm kann gepackt werden. Dafür gibt es verschiedene Ansätze, der UPX Packer wurde speziell für Programme entwickelt, die sich weiterhin normal starten lassen.

Wird die Kompression mit UPX aktiviert, erhöht sich die Buildzeit auf rund 11 Minuten. Leider ist der UPX Packer nicht in der Lage, mehrere CPU Kerne zu nutzen. Das Image ist im Ergebnis mit ca. 71 MB deutlich kleiner.
Die Startzeit bleibt im selben Bereich, wie die der ungepackten Anwendung oder wird sogar leicht besser.

Spring Native ist noch als Beta-Version kommuniziert. Anwendungen können damit jedoch bereits heute für den produktiven Einsatz entwickelt werden. Der Fokus wird dabei jedoch sinnvollerweise auf Anwendungen liegen, die von den geänderten Eigenschaften, wie sehr kurzer Startzeit und dem geringen und besser planbaren Ressourcenbedarf zur Laufzeit auch echten Nutzen beziehen.
Das könnten beispielsweise sehr dynamisch skalierende Function-as-a-Service Anwendungen sein. Java ist damit realistisch in Bereichen einsetzbar, die bisher speziellen Ökosystemen, wie dem ebenfalls statisch gelinkten Go vorbehalten waren. Auch wenn man auf einige vielleicht liebgewonnene Eigenschaften, wie die dynamische Konfiguration der Anwendung oder bestmögliche Performance verzichten muss, gibt es dafür einiges im Gegenzug.

Aus Entwicklersicht bleiben jedoch noch einige Wünsche offen: Manuell diverse Hints zu konfigurieren führt zu viel try-and-error und Rechercheaufwand. Durch die extrem langsamen Builds ist die Turnaroundzeit auch unerträglich hoch. Ein inkrementeller Build für Test und Entwicklung wäre hier mehr als wünschenswert.

Ebenfalls sollte dabei nicht vergessen werden, dass noch nicht alle Libraries mit dem GraalVM native-image einwandfrei funktionieren. Einen eingehenden Blick ist das Thema aber auf jeden Fall wert, zumal der Einstieg mit Spring Boot sehr leicht fällt.

Zu den Themen Kubernetes, Docker und Cloudarchitektur bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:

Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.