Java 11 LTS: Warum jetzt der Umstieg lohnt

Vor gut einem Monat, am 25. September, hat Oracle Java 11 veröffentlicht. Das klingt zunächst nach einem gewöhnlichen Release -- nach Java 9 und 10 also die nächste Nummer in der Reihe. Doch Java 11 ist alles andere als gewöhnlich: Es ist das erste Long-Term-Support-Release seit Java 8 und damit der logische Migrationspfad für die Mehrheit aller Java-Projekte. Für Teams, die Java 9 und 10 bewusst übersprungen haben, ist jetzt der Zeitpunkt gekommen, sich ernsthaft mit dem Umstieg zu befassen.

Die neue Release-Kadenz: Was hat sich geändert?

Oracle hat mit Java 9 die Release-Strategie grundlegend umgestellt. Statt alle paar Jahre ein großes Release mit Dutzenden Features zu veröffentlichen, erscheint jetzt alle sechs Monate eine neue Java-Version. Java 9 kam im September 2017, Java 10 im März 2018, Java 11 im September 2018 -- der Takt ist strikt.

Der entscheidende Punkt: Nicht jede Version bekommt langfristigen Support. Java 9 und 10 waren sogenannte Feature-Releases mit nur sechs Monaten Unterstützung. Nach dem Erscheinen der Folgeversion gab es keine Sicherheitsupdates mehr. Für produktive Systeme war das zu kurzlebig -- verständlicherweise haben viele Teams deshalb auf Java 8 verharrt.

Java 11 ist nun die erste LTS-Version im neuen Modell. Oracle wird sie mindestens bis September 2023 mit Updates versorgen, andere Anbieter wie AdoptOpenJDK oder Red Hat sogar darüber hinaus. Der nächste LTS-Release wird voraussichtlich Java 17 im September 2021 sein. Wer also Stabilität braucht, hat mit Java 11 eine solide Basis für die kommenden Jahre.

Licensing: OpenJDK wird zum Standard

Neben der Release-Kadenz hat Oracle auch die Lizenzierung geändert -- und das sorgt für Verunsicherung. Kurz gefasst: Das Oracle JDK ist ab Java 11 nicht mehr kostenlos für den produktiven Einsatz. Wer das Oracle JDK mit kommerziellem Support nutzen möchte, benötigt eine kostenpflichtige Subskription.

Die gute Nachricht: Das OpenJDK ist funktional identisch und bleibt kostenlos. Oracle selbst hat die verbleibenden Unterschiede zwischen Oracle JDK und OpenJDK mit Java 11 beseitigt. In der Praxis bedeutet das: OpenJDK ist jetzt die Standard-Distribution für die meisten Teams. Wer bisher das Oracle JDK heruntergeladen hat, sollte auf OpenJDK-Builds umstellen -- etwa von AdoptOpenJDK, Amazon Corretto oder den Distribution-eigenen Paketen.

Die wichtigsten Features von Java 9 bis 11

Wer direkt von Java 8 auf 11 migriert, bekommt drei Versionen an Neuerungen auf einmal. Neben dem Modulsystem (JPMS), das wir in einem früheren Artikel ausführlich behandelt haben, sind die folgenden Features besonders praxisrelevant.

Lokale Typinferenz mit var (Java 10)

Mit dem Schlüsselwort var kann der Compiler den Typ einer lokalen Variable aus dem Initialisierungsausdruck ableiten. Das reduziert Boilerplate, besonders bei generischen Typen:

// vorher
Map<String, List<Customer>> customersByCity = getCustomersByCity();
HttpURLConnection connection = (HttpURLConnection) url.openConnection();

// nachher
var customersByCity = getCustomersByCity();
var connection = (HttpURLConnection) url.openConnection();

Wichtig: var ist kein dynamischer Typ wie in JavaScript. Die Variable ist weiterhin stark typisiert -- der Compiler ermittelt den Typ lediglich automatisch. Die Verwendung ist auf lokale Variablen mit Initialisierung beschränkt; für Felder, Parameter oder Rückgabetypen ist var nicht zulässig.

Unser Tipp: var dort einsetzen, wo der Typ aus dem Kontext offensichtlich ist. Bei var result = service.process(input) geht die Lesbarkeit verloren, weil nicht erkennbar ist, welchen Typ result hat.

Neue String-Methoden (Java 11)

Strings bekommen in Java 11 einige überfällige Methoden, die man bisher nur über externe Bibliotheken wie Apache Commons Lang hatte:

// Leerzeichenprüfung -- besser als trim().isEmpty()
"   ".isBlank();           // true
"hello".isBlank();         // false

// Unicode-fähiges Trimming
"  hello  ".strip();       // "hello"
"  hello  ".stripLeading();// "hello  "
"  hello  ".stripTrailing();// "  hello"

// Mehrzeilige Strings verarbeiten
"line1\nline2\nline3".lines().count();  // 3

// String wiederholen
"ab".repeat(3);            // "ababab"

Die strip()-Methoden sind dabei explizit Unicode-fähig und damit trim() vorzuziehen, das nur ASCII-Whitespace entfernt.

Collection Factory Methods (Java 9)

Immutable Collections lassen sich seit Java 9 kompakt erzeugen, ohne auf Collections.unmodifiableList() oder Guava zurückgreifen zu müssen:

var names = List.of("Anna", "Ben", "Clara");
var ids = Set.of(1, 2, 3);
var config = Map.of(
    "host", "localhost",
    "port", "8080"
);

Die resultierenden Collections sind unveränderlich -- jeder Versuch, Elemente hinzuzufügen oder zu entfernen, wirft eine UnsupportedOperationException. Das ist bewusstes API-Design und fördert defensive Programmierung.

HTTP Client (Java 11)

Der neue HTTP Client, der als Incubator-Modul in Java 9 debütierte, ist in Java 11 als fester Bestandteil in java.net.http angekommen. Er ersetzt den betagten HttpURLConnection und unterstützt HTTP/2, WebSockets sowie asynchrone Aufrufe:

var client = HttpClient.newHttpClient();
var request = HttpRequest.newBuilder()
        .uri(URI.create("https://api.example.com/users"))
        .header("Accept", "application/json")
        .GET()
        .build();

var response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());
System.out.println(response.body());

Für viele Projekte, die bisher Apache HttpClient oder OkHttp nur für einfache REST-Aufrufe eingebunden haben, kann der neue Client eine Abhängigkeit weniger bedeuten.

Single-File Execution (Java 11)

Java-Dateien mit einer einzelnen Klasse lassen sich ab Java 11 direkt ausführen, ohne vorheriges Kompilieren:

java HelloWorld.java

Für Produktionscode ist das irrelevant, aber für Scripting, schnelle Prototypen und Lehre eine willkommene Vereinfachung.

Migrationsfallen: Was beim Umstieg bricht

Die Migration von Java 8 auf 11 ist technisch anspruchsvoller als frühere Versionswechsel. Zwei Bereiche verursachen erfahrungsgemäß die meisten Probleme.

Entfernte Java-EE-Module: Java 11 entfernt mehrere Module, die seit Java 9 als deprecated markiert waren. Am häufigsten betroffen: JAXB (javax.xml.bind), JAX-WS (javax.xml.ws), JTA (javax.transaction) und die Common Annotations (javax.annotation). Wer JAXB für XML-Marshalling oder @PostConstruct-Annotationen verwendet, muss die entsprechenden Bibliotheken als explizite Abhängigkeiten einbinden -- etwa jakarta.xml.bind-api und eine Implementierung wie org.glassfish.jaxb.

JavaFX ist nicht mehr im JDK enthalten. Wer JavaFX-Anwendungen baut, muss es als separates SDK einbinden. Für Backend-Entwickler ist das in der Regel unerheblich, aber es kann Build-Skripte betreffen, die eine vollständige JDK-Installation voraussetzen.

Unsere Empfehlung

Für Teams, die noch auf Java 8 sind, ist Java 11 der richtige Migrationszeitpunkt. Die LTS-Unterstützung gibt Planungssicherheit, das Ökosystem hat sich seit Java 9 deutlich stabilisiert, und die meisten gängigen Frameworks -- Spring Boot 2.1, Hibernate 5.3, Jackson 2.9 -- laufen problemlos auf Java 11.

Ein pragmatischer Migrationsplan sieht so aus:

1. OpenJDK 11 aufsetzen und die Build-Toolchain aktualisieren (Maven/Gradle Compiler-Plugin, CI-Server)
2. Kompilieren und Tests laufen lassen -- die meisten Fehler zeigen sich sofort als fehlende Imports für JAXB und Co.
3. Entfernte Module als Abhängigkeiten nachziehen -- in den meisten Fällen genügen drei bis vier zusätzliche Dependencies in der pom.xml oder build.gradle
4. Illegal-Access-Warnungen prüfen -- --illegal-access=deny als JVM-Flag setzen und verbleibende Reflection-Zugriffe auf interne APIs bereinigen
5. Neue Features schrittweise einführen -- var, die neuen String-Methoden und Collection-Factories in neuem Code nutzen

Wir bei encircle360 haben die ersten Services bereits auf Java 11 migriert. Die größte Hürde war die JAXB-Migration bei einem Service mit umfangreicher XML-Verarbeitung -- insgesamt war der Aufwand aber überschaubar und hat sich durch die modernere API und die bessere Performance der neuen JVM bereits gelohnt.