Wann würdest du einen Java-Service zu einem Native Image kompilieren, und was gibst du dafür auf?

Native Image passt zu Workloads, in denen Startzeit und Speicher dominieren: Serverless Functions, Kommandozeilenwerkzeuge und Services, die auf null skalieren, denn es startet in Millisekunden ohne Warmup und mit deutlich kleinerem Footprint. Der Preis ist die Closed-World-Annahme, Reflection, dynamische Proxies und das Laden von Ressourcen müssen also zur Build-Zeit bekannt sein, Builds sind langsam, und der Spitzendurchsatz kann unter dem liegen, was der JIT in einem langlaufenden Prozess erreicht.

Ich greife dazu, wenn die Startzeit auf dem kritischen Pfad liegt. Eine Function, die zweihundert Millisekunden läuft, kann sich keine JVM leisten, die drei Sekunden zum Starten und noch eine Minute zum Warmwerden braucht, und dasselbe Argument gilt für ein Kommandozeilenwerkzeug oder einen Service, der zwischen Traffic-Schüben auf null skaliert. Speicher ist der andere Gewinn, denn ein Native Image läuft mit einem Bruchteil des Heaps. Aufgeben tut man die Dynamik. Ahead-of-Time-Kompilierung nimmt eine geschlossene Welt an, alles, was zur Laufzeit entdeckt wird, Reflection, dynamische Proxies, Service Loading, Resource Bundles, muss also zur Build-Zeit deklariert sein. Moderne Frameworks generieren den Großteil dieser Konfiguration in ihrem Build-Schritt, aber eine Bibliothek, die zur Laufzeit etwas Cleveres macht, scheitert auf eine Art, die nur im nativen Binary auftaucht, die Testsuite muss also auch gegen das Image laufen. Builds dauern außerdem Minuten statt Sekunden, und das Observability-Werkzeug ist weniger ausgereift. Für einen langlaufenden Service mit gleichmäßigem Traffic bleibe ich auf der JVM, denn der JIT schlägt Ahead-of-Time-kompilierten Code beim Spitzendurchsatz irgendwann.