Java 27: Was ist neu?

Julian | Sep 26, 2026 min read
Java 27: Was ist neu?

Dieses Bild wurde KI-generiert.

Hallo zusammen,

seit dem Java-26-Artikel ist wieder ein halbes Jahr vergangen – und wie angekündigt hält Java den Sechs-Monats-Rhythmus konsequent ein. Am 15. September 2026 ist Java 27 erschienen, wieder kein LTS-Release (das nächste kommt erst mit Java 29 im September 2027), aber ein Release mit einer klaren Handschrift: Weniger neue Syntax, dafür Fundament-Arbeit an Speicher, Sicherheit und Diagnostik.

Java 27 bringt neun eigenständige JEPs mit: vier davon sind final, vier stecken in einer weiteren Preview-Runde, einer bleibt im Incubator. Auffällig ist, wie viele der finalen Features nichts an deiner Syntax ändern, aber trotzdem jede Anwendung betreffen, die auf der JVM läuft – vom Garbage Collector bis zur TLS-Verbindung.

Schauen wir uns an, was wirklich ankommt.

Die finalisierten Features

G1 wird zum Standard – ausnahmslos (JEP 523)

Seit Java 9 ist G1 der Standard-Garbage-Collector – mit einer Ausnahme: Maschinen mit nur einer CPU oder weniger als 1.792 MB Arbeitsspeicher bekamen bisher automatisch den einfacheren Serial GC. Diese Ausnahme fällt mit Java 27 weg. Der Grund ist unspektakulär, aber überzeugend: Dank kontinuierlicher Verbesserungen – zuletzt der reduzierten Synchronisation aus Java 26 (JEP 522) – erreicht G1 mittlerweile nahezu den Durchsatz von Serial GC, auch auf schwacher Hardware. Damit lohnt sich die einheitliche Wahl für alle Umgebungen.

Falls du aus gutem Grund bei Serial GC bleiben willst – etwa in sehr kleinen Containern, wo dir jedes Megabyte GC-Overhead wehtut – geht das weiterhin explizit:

java -XX:+UseSerialGC -jar deine-anwendung.jar

Mitgeliefert werden auch zwei kleinere, aber spürbare Anpassungen an G1: Die Heap-Ratio-Defaults (-XX:MinHeapFreeRatio / -XX:MaxHeapFreeRatio) wandern von 40 %/70 % auf 0 %/100 %, was unnötiges Auf- und Abschrumpfen des Heaps reduziert. Und -XX:InitiatingHeapOccupancyPercent heißt jetzt kürzer -XX:G1IHOP.

Objekte auf Diät: Compact Object Headers (JEP 534)

Jedes Java-Objekt trägt unsichtbaren Ballast mit sich herum: den Objekt-Header. Bisher waren das auf 64-Bit-Systemen 96 Bit (12 Byte) – 64 Bit Mark Word für Locking, Hashcode und GC-Infos, plus 32 Bit Class Word für den Zeiger auf die Klasse. Mit Java 27 ist das per Default vorbei: Der Header schrumpft auf 64 Bit (8 Byte), indem Identity-Hashcode, Objekt-Alter, Lock-Bits und ein komprimierter Klassenzeiger enger zusammengepackt werden.

Das klingt nach Mikro-Optimierung, ist aber genau das nicht. Bei Anwendungen mit vielen kleinen Objekten – und das ist in Java die Regel, nicht die Ausnahme – macht sich das mit rund 10–20 % weniger Heap-Verbrauch und 5–10 % mehr Durchsatz bemerkbar. Kein Code-Change nötig, du bekommst das automatisch.

Falls du aus Kompatibilitätsgründen (z. B. natives Tooling, das sich auf das alte Header-Layout verlässt) zurück zum klassischen Header willst:

java -XX:-UseCompactObjectHeaders -jar deine-anwendung.jar

Pro-Tipp: Das Flag ist bereits als deprecated markiert und wird in einer zukünftigen Version verschwinden. Wenn du es aktuell einsetzt, ist das eine Übergangslösung, kein dauerhafter Ausweg – kläre die eigentliche Inkompatibilität, statt dich dauerhaft auf das Flag zu verlassen.

Sauberere Diagnostik: JFR redigiert sensible Daten automatisch (JEP 536)

Der JDK Flight Recorder (JFR) zeichnet unter anderem Programmargumente und Umgebungsvariablen auf – praktisch für die Fehlersuche, aber gefährlich, wenn dort aus Versehen ein API-Key oder ein Passwort landet. Java 27 macht damit Schluss: JFR erkennt sensible Schlüssel-Muster automatisch und ersetzt die Werte innerhalb des Prozesses, bevor sie überhaupt in die Aufzeichnung gelangen.

Standardmäßig werden Muster wie *password*, *secret*, *token*, *api*key* oder *credential* case-insensitive erkannt und redigiert:

# Zusätzliche Schlüssel redigieren
java -XX:FlightRecorderOptions:'redact-key=ACCESS_TOKEN;*keyStorePassword' -jar app.jar

# Eigene Liste aus Datei laden
java -XX:FlightRecorderOptions:'redact-key=@keys.txt' -jar app.jar

# Defaults erweitern statt ersetzen
java -XX:FlightRecorderOptions:'redact-key=+*confidential*' -jar app.jar

# Redaction komplett abschalten (nicht empfohlen)
java -XX:FlightRecorderOptions:'redact-key=none,redact-argument=none' -jar app.jar

In der Aufzeichnung erscheint der Wert dann als [REDACTED] statt im Klartext. Für Teams, die JFR-Dumps aus der Produktion zur Analyse weiterreichen – an Kollegen, in Ticket-Systeme, an externe Support-Partner – ist das ein handfester Gewinn an Sicherheit, ohne dass du dafür etwas konfigurieren musst.

Deep-Dive: Post-Quantum TLS wird Standard (JEP 527)

Das strategisch relevanteste JEP in diesem Release betrifft dich vermutlich, ohne dass du auch nur eine Zeile Code anfassen musst. Der Hintergrund: Verschlüsselte Verbindungen, die heute abgefangen und gespeichert werden, könnten in einigen Jahren mit einem ausreichend leistungsfähigen Quantencomputer entschlüsselt werden. Dieses Angriffsmuster heißt “Harvest now, decrypt later” – Daten werden heute gesammelt, in der Zukunft geknackt.

Java 27 begegnet dem mit hybridem Schlüsselaustausch für TLS 1.3: Der klassische, elliptische-Kurven-basierte ECDHE-Austausch wird mit dem quantenresistenten ML-KEM kombiniert. Beide Verfahren laufen parallel, ein Angreifer müsste also beide brechen, um die Verbindung zu kompromittieren.

Standardmäßig aktiv ist die Variante X25519MLKEM768. Zwei weitere stehen zur Verfügung, falls dein Sicherheitsprofil andere Kurven verlangt:

# Alternative Kombinationen aktivieren
java -Djdk.tls.namedGroups=SecP256r1MLKEM768 -jar deine-anwendung.jar
java -Djdk.tls.namedGroups=SecP384r1MLKEM1024 -jar deine-anwendung.jar

Der eigentliche Clou: Jede Anwendung, die über die Standard-APIs aus javax.net.ssl mit TLS 1.3 kommuniziert, bekommt den Schutz automatisch – ohne Code-Änderung, ohne Rebuild. Das ist kein Preview-Feature zum Ausprobieren, sondern ab Java 27 aktive Realität in jeder TLS-1.3-Verbindung, die dein Code aufbaut.

Pro-Tipp: Wenn deine Anwendung hinter restriktiven Firewalls, Load Balancern oder TLS-terminierenden Proxies läuft, die den TLS-Handshake genau parsen, teste die Verbindung gezielt gegen Java 27. Hybride Schlüsselaustausch-Verfahren vergrößern das ClientHello-Paket spürbar – ältere Middleboxes, die auf feste Paketgrößen ausgelegt sind, können damit Probleme bekommen.

Was als Preview weiter reift

Lazy Constants (JEP 531, 3. Preview)

Die API rund um verzögert initialisierte, aber trotzdem finale Werte wird geschärft. Die Low-Level-Methoden isInitialized() und orElse() fliegen raus, dafür kommt mit Set.ofLazy() die letzte fehlende Collection-Variante dazu:

private final LazyConstant<Validator> validator =
    LazyConstant.of(this::createValidator);

// createValidator() läuft erst beim ersten get()
public boolean isValid(String input) {
    return validator.get().test(input);
}

// Auch für Sets: jedes Element wird erst bei Bedarf berechnet
private final Set<String> enabledFeatures =
    Set.ofLazy(candidateFeatures, this::isFeatureEnabled);

Damit stehen jetzt lazy Varianten für List, Map und Set zur Verfügung – konsistent nutzbar, egal welche Collection du für teure, aufgeschobene Initialisierung brauchst.

Primitive Types in Patterns, instanceof und switch (JEP 532, 5. Preview)

Unverändert gegenüber Java 26 erneut zur Preview eingereicht – ein Zeichen, dass hier kein API-Streit mehr offen ist, sondern nur noch der reguläre Preview-Prozess durchlaufen wird. Pattern Matching auf primitiven Typen funktioniert inklusive switch mit Guard-Bedingungen:

int score = ermittleScore();
String bewertung = switch (score) {
    case int s when s >= 90 -> "sehr gut";
    case int s when s >= 75 -> "gut";
    default -> "ausbaufähig";
};

Der Compiler prüft dabei genau, ob ein Wert verlustfrei in den jeweiligen Zieltyp passt – 0.25 passt in ein float, 0.1 nicht, weil sich der Wert nicht exakt darstellen lässt. Diese Präzisionsprüfung ist der Kern des Features und bleibt gegenüber Java 26 unverändert.

Structured Concurrency (JEP 533, 7. Preview)

Anders als die letzten beiden Previews bringt Structured Concurrency in dieser Runde spürbare API-Änderungen mit – ein Vorzeichen, dass die Finalisierung näher rückt (angepeilt für Java 28). Wer die letzten Previews im Einsatz hatte, sollte genau hinschauen:

  • FailedException ist Geschichte, stattdessen wirft join() jetzt ExecutionException – konsistent zum Verhalten von Future.get()
  • Joiner bekommt einen dritten Typparameter für den Exception-Typ: Joiner<T, R, R_X>
  • Joiner.onTimeout() heißt jetzt schlicht timeout()
  • awaitAll() als Joiner-Variante wurde entfernt
  • Scopes öffnest du jetzt über StructuredTaskScope.open(cfg -> cfg.withTimeout(...).withName(...))
try (var scope = StructuredTaskScope.open(
        Joiner.<GeoCoordinates>anySuccessfulOrThrow())) {
    scope.fork(() -> primaryGeocoder.lookup(address));
    scope.fork(() -> backupGeocoder.lookup(address));
    return scope.join(); // liefert das erste erfolgreiche Ergebnis, bricht den Rest ab
}

Zwei Geocoding-Dienste, ein Ergebnis, sauberer Abbruch des langsameren Kandidaten – genau das Muster, für das Structured Concurrency gedacht ist. Der Preis für die Reife: Wenn du bereits produktiv mit einer früheren Preview experimentierst, erwartet dich hier ein Migrationsaufwand.

PEM Encodings of Cryptographic Objects (JEP 538, 3. Preview)

Die API zum Ver- und Entschlüsseln kryptografischer Objekte im PEM-Format (Keys, Zertifikate, Revocation-Listen) bleibt in der Grundnutzung stabil, ein paar Klassen- und Methodennamen wurden gegenüber Java 26 verschlankt:

PrivateKey privateKey = PEMDecoder.of()
    .withDecryption(passphrase.toCharArray())
    .decode(encryptedPemText, PrivateKey.class);

String encoded = PEMEncoder.of()
    .withEncryption(passphrase.toCharArray())
    .encodeToString(privateKey);

Kein Griff mehr zu Drittanbieter-Bibliotheken nur für PEM-Handling – für Enterprise-Security-Setups, in denen Zertifikatsverwaltung zum Alltag gehört, spart das Boilerplate und Fehlerquellen.

Vector API (JEP 537, 12. Incubator)

Unverändert zu Java 26 erneut im Incubator – die zwölfte Runde. Die Vector API kompiliert Vektor-Operationen zur Laufzeit in optimale CPU-Instruktionen und beschleunigt damit Data-Analytics-, KI-Inferenz- und wissenschaftliche Workloads spürbar gegenüber skalaren Operationen:

static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

void addiereVektoren(float[] a, float[] b, float[] c) {
    int upperBound = SPECIES.loopBound(a.length);
    for (int i = 0; i < upperBound; i += SPECIES.length()) {
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        va.add(vb).intoArray(c, i);
    }
}

Der Grund für die lange Incubator-Phase: Die API wartet auf Value Classes aus Project Valhalla, die für Java 28 als Preview erwartet werden. Erst damit kann die Vector API ohne Umwege über Objekt-Wrapper wirklich rund werden.

Pro-Tipps / Warnungen

G1 auf Legacy-Umgebungen testen: Wenn du Anwendungen auf sehr kleinen Instanzen oder in stark limitierten Containern betreibst, die bisher implizit Serial GC bekommen haben, teste dein Deployment gezielt mit Java 27. Der Wechsel ist für die meisten Fälle unsichtbar, aber “die meisten Fälle” ist kein Ersatz für einen eigenen Loadtest.

Structured Concurrency: Preview bleibt Preview: Die API-Änderungen in JEP 533 zeigen, wie viel sich zwischen zwei Preview-Runden noch ändern kann. Baue nichts Produktionskritisches auf einer Preview-API auf, die du nicht bereit bist, bei jedem Release neu anzupassen – auch wenn die Finalisierung für Java 28 in Sicht ist.

Post-Quantum TLS gegen deine Infrastruktur testen: Bevor du Java 27 in Produktion bringst, prüfe TLS-Verbindungen durch Proxies, Load Balancer und Firewalls hindurch. Größere Handshake-Pakete sind ein einfacher, aber leicht übersehener Kompatibilitäts-Fallstrick.

Fazit: Fundament statt Feuerwerk

Java 27 ist wie sein Vorgänger kein Release der großen Ankündigungen – die eigentliche Substanz liegt unter der Oberfläche. G1 als einheitlicher Standard-Collector, kompaktere Objekt-Header und automatisch redigierte JFR-Aufzeichnungen sind drei Verbesserungen, die jede Anwendung betreffen, ohne dass du dafür Code anfassen musst. Der eigentliche Hebel ist aber JEP 527: Mit Post-Quantum-TLS als Standardverhalten macht Java einen der ersten großen, für Entwickler unsichtbaren Schritte in Richtung einer quantensicheren Zukunft.

Die Previews – allen voran der API-Umbau bei Structured Concurrency – zeigen, dass die Finalisierung dieses langjährigen Projekts näher rückt. Mit Java 28 im März 2027 dürfte sich das bestätigen, dazu kommen dann voraussichtlich erste Vorboten von Project Valhalla in Form von Value Classes. Bis dahin lohnt sich ein Blick auf Java 27, besonders wenn Speicherverbrauch oder TLS-Absicherung bei dir gerade Thema sind.

Dieser Text wurde mithilfe von KI erstellt.