Java-Framework: Nativ testen mit Native Spring 0.10

Neue native Build Tools und ein Gradle-Plug-in erweitern die Möglichkeiten zum Bauen und Testen nativer Applikationen mit dem Framework.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen

(Bild: LilKar/Shutterstock.com)

Lesezeit: 3 Min.

Das von VMware gestartete Open-Source-Projekt Spring Native hat Version 0.10.0 erreicht. Das Framework kompiliert Spring-Boot-Applikationen, die zur Laufzeit keine Java Virtual Machine (JVM) benötigen. Stattdessen nutzt das Projekt die virtuelle Maschine GraalVM, um native Images zu erstellen, die alle benötigten Klassen und Libraries enthalten und sich daher als eigenständige Executables verteilen lassen. Spring Native 0.10.0 bietet dafür nun alternativ zu Maven neue native Build Tools und ein Gradle-Plug-in, mit denen sich die Applikationen auch mit einem lokalen Compiler bauen und testen lassen.

Das Update der Spring Native Beta baut auf Spring Boot 2.5 und GraalVM 21.1 auf. An die Stelle des bisherigen native-image-maven-plugin treten die Native Build Tools aus dem GraalVM-Projekt. Das Repository enthält neben einem neuen Maven-Plug-in auch eines für Gradle, sodass Entwicklerinnen und Entwicklern nun beide Build Tools für GraalVM Native Image verwenden können.

Über den Build von Applikationen via mvn -Pnative -DskipTests package oder gradle nativeBuild hinaus, bietet das Update von Spring Native außerdem erweiterte Testing-Optionen. So lassen sich unter anderen JUnit-5-Tests mit mvn -Pnative test oder gradle nativeTest sowie @SpringBootTest als native-image durchführen. Laut Blog-Ankündigung sei damit ein entscheidender Schritt in Richtung höherer Qualität und Wartbarkeit auch von nativen Spring-Boot-Anwendungen erreicht worden.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Während die nativen Images typischerweise schneller starten und weniger Speicher benötigen als reguläre JVM-Anwendungen, müssen Entwicklerinnen und Entwickler aber auch Nachteile in Kauf nehmen, wie einen längeren Build-Prozess und weniger Optionen zur Runtime-Optimierung. Auch müssen Proxies während des Builds festgelegt werden, wofür in Spring Native bisher lediglich auf Interfaces anwendbare JDK Proxies zur Verfügung standen. Proxies für Klassen fehlten, weil das Erzeugen von Bytecode zur Laufzeit – anders als bei der JVM – nicht möglich ist. Die neue @AotProxyHint-Annotation behebt dieses Manko, sodass sich nun auch bereits während des Builds auf Klassen abzielende, Proxy-basierte Mechanismen wie Transaktionen oder Security einrichten lassen.

// Typical security use case of a class proxy now supported on native
@Service
public class GreetingService {

    public String hello() {
        return "Hello!";
    }

    @PreAuthorize("hasRole('ADMIN')")
    public String adminHello() {
        return "Goodbye!";
    }
}

Um die Anzahl der dabei benötigten expliziten Hinweise zu reduzieren, will das Entwicklerteam hinter Spring Native noch die automatische Erkennung solcher Muster verfeinern. Mit Blick auf das nächste Release 0.11 werde zudem an einer funktionalen Konfiguration für die Ahead-of-Time-(AOT)-Transformation gearbeitet. Weitergehende Informationen zu allen Verbesserungen und Bugfixes in Spring Native 0.10.0 finden sich im Blogbeitrag. Der Sourcecode steht auf GitHub.

(map)