{"id":53935,"date":"2025-12-03T21:29:04","date_gmt":"2025-12-03T20:29:04","guid":{"rendered":"https:\/\/www.happycoders.eu\/?p=53935"},"modified":"2025-12-04T09:42:56","modified_gmt":"2025-12-04T08:42:56","slug":"java-26-features","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/java\/java-26-features\/","title":{"rendered":"Java 26 Features (mit Beispielen)"},"content":{"rendered":"\n

Java 26 befindet sich seit dem 4. Dezember 2025 in der sogenannten \u201eRampdown Phase One\u201d, d. h. es werden keine weiteren JDK Enhancement Proposals (JEPs) in das Release aufgenommen. Das Feature-Set steht also fest. Es werden nur noch Bugs gefixt und ggf. kleinere Verbesserungen durchgef\u00fchrt.<\/p>\n\n\n\n

Als Ver\u00f6ffentlichungsdatum ist der 17. M\u00e4rz 2026 angepeilt. Die aktuelle Early-Access-Version kannst du hier<\/a> herunterladen.<\/p>\n\n\n\n

Java 26 geh\u00f6rt mit 10 gelieferten JDK Enhancement Proposals (JEPs) zu den \u00fcberschaubareren Releases der letzten Jahre. Die H\u00e4lfte der JEPs sind kleinere bis mittelgro\u00dfe \u00c4nderungen \u2013 wie Warnungen bei der Mutation von finalen Feldern<\/a> und die Unterst\u00fctzung von HTTP\/3<\/a>.<\/p>\n\n\n\n

Die andere H\u00e4lfte sind wiedervorgelegte Previews \u2013 also Aktualisierungen von bereits vorgestellten, aber noch nicht finalisierten Features. Bis auf bei Lazy Constants<\/a> (zuvor bekannt als Stable Values<\/em>) gab es hier nur minimale \u00c4nderungen.<\/p>\n\n\n\n

F\u00fcr alle JEPs und \u00c4nderungen aus den Release Notes verwende ich wie immer die originalen, englischen Bezeichnungen.<\/p>\n\n\n\n\n\n

Prepare to Make Final Mean Final \u2013 JEP 500<\/h2>\n\n\n\n

Die meisten Entwickler:innen gehen davon aus, dass ein Feld, das wir als final<\/code> kennzeichnen, nicht ver\u00e4nderbar ist. Tats\u00e4chlich k\u00f6nnen wir einem final<\/code>-Feld auch nicht einfach per Gleich-Zeichen einen neuen Wert zuweisen. Allerdings erlaubt es uns die sogenannte Deep Reflection<\/a>, diese Einschr\u00e4nkung zu umgehen.<\/p>\n\n\n\n

Hier eine kleine Beispielklasse, der wir im Konstruktor einen Wert \u00fcbergeben, der dann in dem finalen Feld value<\/code> gespeichert wird:<\/p>\n\n\n

public<\/span> class<\/span> Box<\/span> <\/span>{\n  private<\/span> final<\/span> Object value;\n\n  public<\/span> Box<\/span>(Object value)<\/span> <\/span>{\n    this<\/span>.value = value;\n  }\n\n  @Override<\/span>\n  public<\/span> String toString<\/span>()<\/span> <\/span>{\n    return<\/span> \"Box{value=\"<\/span> + value + \"}\"<\/span>;\n  }\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Der folgende Code zeigt, wie sich der Inhalt des finalen Feldes kinderleicht \u2013 sogar von au\u00dferhalb des Objekts \u2013 \u00e4ndern l\u00e4sst:<\/p>\n\n\n
Box box = new<\/span> Box(\"Rubic's Cube\"<\/span>);\n\nIO.println(\"box = \"<\/span> + box);\n\nField valueField = Box.class<\/span>.getDeclaredField<\/span>(\"value<\/span>\")<\/span>;\nvalueField.setAccessible(true<\/span>);\nvalueField.set(box, \"Magic Wand\"<\/span>);\n\nIO.println(\"box = \"<\/span> + box);<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Wir umgehen hier sowohl die Kapselung des Feldes per private<\/code> als auch die Unver\u00e4nderlichkeit via final<\/code>. Und dieser Code l\u00e4sst sich von beliebiger Stelle aus ausf\u00fchren, beispielsweise auch von Drittanbieter-Libraries, von denen wir nicht mal wissen, dass sie auf dem Classpath liegen. <\/p>\n\n\n\n
Zudem kam ebenfalls in Java 16 die \u201eStrong Encapsulation\u201c f\u00fcr JDK-Interna. Seitdem m\u00fcssen wir Deep Reflection \u00fcber Modulgrenzen hinweg explizit mit --add-opens<\/code> erlauben. Das funktioniert bei eigenen Anwendungen aber nur, wenn diese auch das Modulsystem nutzen.<\/p>\n\n\n\n
Um Java sicherer zu machen, soll die Modifkation finaler Felder per Deep Reflection in Zukunft grunds\u00e4tzlich verboten werden \u2013 auch innerhalb eines Moduls.<\/p>\n\n\n\n
Warnungen ab Java 26<\/h4>\n\n\n\n
In Java 26 werden durch JDK Enhancement Proposal 500<\/a> als ein erster Schritt Warnungen eingef\u00fchrt. Der oben gezeigte Code l\u00e4sst sich unter Java 25 anstandslos ausf\u00fchren; unter Java 26 zeigt er nun folgende Warnung an:<\/p>\n\n\n
WARNING: Final field value in class eu.happycoders.java26.jep500.Box has been mutated reflectively by class eu.happycoders.java26.jep500.FinalTest in unnamed module @3f99bd52\nWARNING: Use --enable-final-field-mutation=ALL-UNNAMED to avoid a warning\nWARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Die Nutzung von Deep Reflection kann per --enable-final-field-mutation=<Modulname><\/code> explizit f\u00fcr bestimmte Module erlaubt \u2013 und damit die Warnung verhindert werden.<\/p>\n\n\n\n
In einer zuk\u00fcnftigen Java-Version soll Deep Reflection dann standardm\u00e4\u00dfig verboten sein \u2013 statt einer Warnung wird es dann zu einer Exception kommen, sofern Deep Reflection nicht per --enable-final-field-mutation<\/code> explizit erlaubt ist.<\/p>\n\n\n\n
Das zuk\u00fcnftige Verhalten kann bereits jetzt durch die VM-Option --illegal-final-field-mutation<\/code> eingeschaltet werden. Die Option bietet folgende M\u00f6glichkeiten:<\/p>\n\n\n\n
--illegal-final-field-mutation=allow<\/code><\/td>Finale Felder k\u00f6nnen ohne Warnung ver\u00e4ndert werden (Standardverhalten vor Java 26).<\/td><\/tr>
--illegal-final-field-mutation=warn<\/code><\/td>Beim erstmaligen<\/em> \u00c4ndern eines finalen Feldes erscheint eine Warnung (Standardverhalten ab Java 26).<\/td><\/tr>
--illegal-final-field-mutation=debug<\/code><\/td>Bei jedem<\/em> \u00c4ndern eines finalen Feldes erscheint eine Warnung.<\/td><\/tr>
--illegal-final-field-mutation=deny<\/code><\/td>Finale Felder d\u00fcrfen nicht ge\u00e4ndert werden \u2013 der Versuch f\u00fchrt zu einer IllegalAccessException<\/code>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
In einer zuk\u00fcnftigen Java-Version wird deny<\/code> zur Standardeinstellung werden, und allow<\/code> wird nicht mehr erlaubt sein. Dann muss Deep Reflection auf Modulebene per --enable-final-field-mutation<\/code> aktiviert werden. <\/p>\n\n\n\n
Die Garantie, dass finale Felder wirklich final sind, sch\u00fctzt \u00fcbrigens nicht nur vor unerwartetem Verhalten, sondern sie verbessert auch die Performance einer Anwendung: Wenn die JVM wei\u00df, dass ein Feld nicht ver\u00e4ndert werden kann, dann kann es den Zugriff darauf per Constant Folding<\/a> \u2013 eine Art Inlining f\u00fcr Konstanten \u2013 optimieren.<\/p>\n\n\n\n
Ahead-of-Time Object Caching with Any GC \u2013 JEP 516<\/h2>\n\n\n\n
In Java 24<\/a> wurde Ahead-of-Time Class Loading & Linking<\/a> eingef\u00fchrt \u2013 die M\u00f6glichkeit, die von einer Anwendung ben\u00f6tigten Klassen in einem architekturspezifischen Bin\u00e4rformat in einem sogenannten Ahead-of-Time-Cache zu speichern \u2013 und aus diesem zu laden, um den Start von Anwendungen deutlich zu beschleunigen (in Tests um bis zu 42 %).<\/p>\n\n\n\n
Bisher wurden die Klassen exakt so im Cache gespeichert, wie sie der Garbage Collector auf dem Heap ablegt, einschlie\u00dflich Header ud Referenzen auf andere Objekte (z. B. von Class<\/code>-Objekten auf Strings). Dies hat den Vorteil, dass die Ahead-of-Time-Cache-Datei direkt vom Dateisystem in den Heap gemappt werden kann \u2013 und das geschieht nahezu ohne Zeitverlust, wenn die Ahead-of-Time-Cache-Datei im Dateisystem-Cache liegt.<\/p>\n\n\n\n
Allerdings kann sich die Bin\u00e4rdarstellung sowohl der Objekt-Header als auch der Referenzen von Garbage Collector zu Garbage Collector oder abh\u00e4ngig von VM-Optionen unterscheiden: <\/p>\n\n\n\n
Dieses Problem wurde bereits vor Jahren erkannt, und daher wurde bei Hidden Classes in Java 15<\/a> und bei Records<\/a> in Java 16<\/a> von Beginn an Deep Reflection gar nicht erst erlaubt.<\/p>\n\n\n\n