Serguey Asael Shinder: JDK 28 has six JEPs targeted, and one of them puts a JSON parser in the JDK
Serguey Asael Shinder3 min readOpenJDK tagged build 16 of JDK 28 on 17 September (https://github.com/openjdk/jdk/releases/tag/jdk-28%2B16). The project page lists six JEPs targeted so far: 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, and 542 PEM Encodings of Cryptographic Objects.
JEP 540 states its goal as defining "a simple, standard API for parsing and generating JSON documents so that doing so does not require an external library", restricted to RFC 8259 and explicitly leaving out data binding, streaming and syntax extensions (https://openjdk.org/jeps/540).
What it means
Two of these six are worth planning around; the rest are worth knowing about.
Generational Shenandoah becoming the default is the one that changes behaviour on machines nobody reconfigured. If you run Shenandoah and your pause and footprint numbers came from measurements, re-measure on an early-access build before the GA notes tell you what you should have seen. A default that flips is not a feature you opt into.
The macOS/x64 deprecation has a date attached to somebody's hardware refresh, not yours: it is the Intel Mac build being marked for removal. If any part of your release pipeline still produces or tests on Intel macOS, that is now a countdown, and the cheapest moment to find out is while it is still a deprecation.
The JSON API is the headline everyone will repeat, and it deserves the least urgency. It is an incubator module: it ships behind --add-modules, the package name will change, and it is explicitly not a replacement for Jackson in an application that binds JSON to objects. Where it genuinely helps is the place a JSON dependency is most annoying — a small tool, a build plugin, a test fixture.
What I would not do is read a targeted list as a promise. Targeted means targeted; JEPs have been dropped between rampdown and GA before, and an incubating API is the one kind of feature you must expect to move under you.
The two previews are the interesting half
Value Objects and Strict Field Initialization both change what the JVM can assume about an object, and both are the long tail of the same project: making the runtime able to treat some classes as pure data. Neither is something to adopt in application code this year; both are worth reading now, because they shape what the next five years of library APIs will look like.
Strict field initialization in particular closes a hole that has been quietly expensive: a constructor that publishes this before its fields are set. Every team that has chased a once-a-month null in a field that "cannot be null" has met this, and the current answer is discipline rather than enforcement.
What to do about an early-access build
Run your test suite on it, and nothing else. An EA build tells you whether your dependencies survive the next JDK, which is the only question with a deadline; it tells you almost nothing about performance, because the numbers move up to GA.