JDK 28 Picks Up a Built-In JSON API, Strict Field Initialization and the macOS/x64 Deprecation
Three more JEPs moved past the proposal stage this week and are now integrated in JDK 28. The one most developers will notice is JEP 540, Simple JSON API (Incubator). It adds a jdk.incubator.json module with a sealed JsonValue hierarchy (JsonObject, JsonArray, JsonString, JsonNumber, JsonBoolean, JsonNull) and a Json entry point for parsing and generating RFC 8259 documents. Because it is an incubator module, you have to enable it with --add-modules jdk.incubator.json. The API is built for exploratory navigation with very little code, e.g. Json.parse(body).get("properties").get("periods").asList(), followed by a stream over the values.
The JEP lists its non-goals explicitly: no data binding, no streaming parser, no JSON5 or other syntax extensions, and no attempt to replace Jackson or Gson. It covers the cases where you just want to read a config file or a REST response without pulling in a dependency, such as single-file scripts, small tools and tests.
JEP 539, Strict Field Initialization in the JVM (Preview), is a VM-level feature for language implementers. Fields flagged ACC_STRICT_INIT must be written before they are read. For instance fields, the assignment has to happen in the "early larval" phase before super() returns, and the verifier enforces this rather than a runtime check. For static fields, reads before initialization are rejected. This closes a long-standing hole where circular class initialization can expose a field's default 0/null value, and it is groundwork for Valhalla's value classes. JEP 541 deprecates the macOS/x64 port for removal. Building it now needs --enable-deprecated-ports, and Oracle stops maintaining the port after JDK 27.
Read more — OpenJDK
Performance Improvements in JDK 27: Collections, GC Defaults, Vectorization and Compact Headers
The Java team's annual performance write-up for JDK 27 collects dozens of smaller changes into one picture. In the core libraries, specialized fast paths for copying from a HashMap or an unmodifiable map (JDK-8371656) speed up bulk copies by 61–86%. Copying a 150-entry unmodifiable map dropped from about 10.6 µs to 1.5 µs. AttributedString was restructured around a map (35–40% faster iteration, about 20% less allocation), URL.toString() got 60%+ faster, and removing a redundant fstat call cut FileOutputStream operations by 14%. Crypto intrinsics improved AES/ECB throughput by 37% on recent Intel parts and SHA-3 by 16–39% with AVX2.
On the runtime side, the headline changes are the defaults that shipped with JDK 27. G1 is now the default collector everywhere (JEP 523), including the small-container configurations that used to fall back to Serial. Compact Object Headers are on by default (JEP 534), shrinking headers from 12 to 8 bytes, and the post cites a 22% heap reduction and 8% CPU savings on SPECjbb2015. The new object monitor table, which moves monitor mappings out of the header, is also enabled by default.
The JIT section covers SuperWord auto-vectorization of subword casts and removal of redundant vector-mask casts, which produced 2.3–3.8x throughput gains on NVIDIA Grace systems. It also covers broader KnownBits analysis and the return of constant folding for Math.pow(). If you're planning a JDK 21 → 27 migration, use this post to work out which wins you get just by upgrading and which defaults (GC, headers) you should re-baseline in your own load tests.
Read more — Inside.java
JDK Intrinsics Make ML-KEM and ML-DSA Two to Four Times Faster
With post-quantum algorithms now in the platform (ML-KEM for key encapsulation per FIPS 203, ML-DSA for signatures per FIPS 204, and HSS/LMS verification per RFC 8554), the next job is making them fast enough for default use in TLS. A new Inside.java article explains how HotSpot intrinsics speed up the hot loops of these algorithms. The targets are the forward and inverse number-theoretic transforms over 256-coefficient polynomials, NTT-domain multiplication, polynomial addition, Barrett reduction, and bit packing/unpacking.
ML-KEM and ML-DSA look alike on paper, but different moduli and coefficient representations mean each needs its own intrinsics. ML-DSA also has algorithm-specific ones such as the Dilithium polynomial decompose step. HSS/LMS verification is dominated by SHA-256, so it benefits mostly from the existing SHA intrinsics.
On JDK 28 builds, the reported throughput gains are roughly 218–437% for ML-KEM depending on parameter set (512/768/1024), about 150–350% for ML-DSA, and 80–120% for HSS/LMS verification. These were measured on both Ampere Altra (aarch64) and Ice Lake Xeon (x64) servers. Teams preparing for hybrid PQC key exchange should now see a much smaller handshake cost than early benchmarks suggested.
Read more — Inside.java
JDK 28 Adds a @note Tag to JavaDoc
The OpenJDK Quality Outreach program is asking library maintainers to try a new JavaDoc feature in JDK 28 early-access builds: a standard @note tag for tips and warnings inside API docs. It works inline ({@note There is always a maximum foo, even if the list is empty.}) or as a block tag, and renders with a "Note:" header by default.
The tag takes optional attributes. header changes the label (for example "Caution:" or "Warning:"), kind adds a CSS class for custom styling, and id sets an HTML anchor. Projects can also define aliases with the existing -tag option, for example javadoc -tag 'warning:A:Warning:' to get a dedicated @warning tag.
Today many libraries fake callouts with raw HTML <p><b>Note:</b> blocks or custom taglets, so this is a small change that removes friction. Maintainers are asked to build their docs with JDK 28 EA, try the tag, and report issues to the javadoc-dev mailing list (see JDK-8363700 for customization details).
Read more — Inside.java
Links & Sources
You May Also Enjoy
