Serguey Asael Shinder: Für JDK 28 sind sechs JEPs gesetzt — eines bringt einen JSON-Parser ins JDK
Serguey Asael Shinder2 Min. LesezeitOpenJDK hat am 17. September Build 16 von JDK 28 getaggt (https://github.com/openjdk/jdk/releases/tag/jdk-28%2B16). Auf der Projektseite stehen bislang sechs JEPs: 401 Value Objects (Preview), 535 Shenandoah GC: Generational Mode by Default, 539 Strict Field Initialization in the JVM (Preview), 540 Simple JSON API (Incubator), 541 Deprecate the macOS/x64 Port for Removal und 542 PEM Encodings of Cryptographic Objects.
JEP 540 nennt als Ziel eine „einfache, standardisierte API zum Parsen und Erzeugen von JSON-Dokumenten, sodass dafür keine externe Bibliothek nötig ist" — beschränkt auf RFC 8259, ausdrücklich ohne Data Binding, Streaming und Syntaxerweiterungen (https://openjdk.org/jeps/540).
Was das bedeutet
Zwei dieser sechs sind planungsrelevant, der Rest ist Kenntnisnahme.
Generationelles Shenandoah als Standard ändert das Verhalten auf Maschinen, die niemand umkonfiguriert hat. Wer Shenandoah einsetzt und seine Pausen- und Speicherzahlen aus Messungen hat, sollte auf einem Early-Access-Build neu messen — bevor die GA-Notes erklären, was man hätte sehen sollen. Ein Standard, der kippt, ist kein Feature, für das man sich entscheidet.
Die Deprecation des macOS/x64-Ports hat ein Datum, das am Hardwarezyklus anderer Leute hängt: Es geht um den Intel-Mac-Build. Wenn irgendein Teil der Release-Pipeline noch auf Intel-macOS baut oder testet, läuft ab jetzt eine Uhr — und der billigste Moment, das zu merken, ist, solange es eine Deprecation ist.
Die JSON-API ist die Schlagzeile, die alle wiederholen werden, und verdient die geringste Eile. Es ist ein Incubator-Modul: Es kommt hinter --add-modules, der Paketname wird sich ändern, und ein Ersatz für Jackson in einer Anwendung mit Objekt-Mapping ist es ausdrücklich nicht. Wirklich hilfreich ist es dort, wo eine JSON-Abhängigkeit am meisten stört — kleines Werkzeug, Build-Plugin, Test-Fixture.
Was ich nicht tun würde: eine Liste gesetzter JEPs für ein Versprechen halten. „Targeted" heißt „gesetzt"; JEPs sind zwischen Rampdown und GA schon herausgefallen, und eine inkubierende API ist genau die Art Feature, die sich noch bewegt.
Die beiden Previews sind die interessantere Hälfte
Value Objects und Strict Field Initialization verändern beide, was die JVM über ein Objekt annehmen darf, und beide sind der lange Ausläufer desselben Vorhabens: die Laufzeit in die Lage zu versetzen, manche Klassen als reine Daten zu behandeln. Keines davon gehört dieses Jahr in Anwendungscode; beide lohnen das Lesen jetzt, weil sie prägen, wie Bibliotheks-APIs der nächsten fünf Jahre aussehen werden.
Vor allem die strikte Feldinitialisierung schließt eine Lücke, die still teuer war: ein Konstruktor, der this veröffentlicht, bevor seine Felder gesetzt sind. Jedes Team, das einmal im Monat einem null in einem Feld nachgejagt ist, das „nicht null sein kann", ist ihr begegnet — und die heutige Antwort heißt Disziplin statt Durchsetzung.
Was man mit einem Early-Access-Build macht
Die eigene Testsuite darauf laufen lassen, sonst nichts. Ein EA-Build sagt, ob die Abhängigkeiten das nächste JDK überleben — die einzige Frage mit einer Frist. Über Performance sagt er fast nichts, weil sich die Zahlen bis zur GA noch bewegen.