The rename is the item with a date attached. The finalised API calls the interface BinaryEncodable, and the stated reason is accuracy: what sits inside PEM text is binary data, and DER was too narrow a label for it [6]. If you implemented or referenced DEREncodable while the feature was in preview, you have a source-level edit, and the compiler will find every site for you [6][2]. That is the cheapest kind of break. It is also the kind that previewing three times exists to produce.
Count the releases. The API previewed in JDK 25, 26 and 27, which is three rounds, so JDK 28 is the fourth JDK to carry it and the first to carry it under the final names [14].
The second change is quieter. The PEM record class becomes a regular class, and the reason given is convenience: a plain class can offer constructors that accept Base64-encoded content in byte arrays [5]. The roundup does not say what a record made awkward, only that the reclassification buys those constructors. Practically, it means a caller holding a PEM body as bytes can hand them straight to a constructor. The scope around it stays narrow and explicit: keys, certificates and certificate revocation lists, encoded to PEM and decoded back [3], with conversions defined against PKCS #8 and X.509 binary formats [4].
Elsewhere in the same week, GraalVM 25.3 ships a SubstratePriorityInliningPhase class implementing a priority inliner for both JIT and Native Image, described as improving the performance of generated code [11]. No figure is attached to that description. An inliner change is a policy change applied to your call graph, so the improvement transfers only if your hot paths have the shape the new heuristic prefers: small callees called from a few dominant sites, and enough inlining budget left for it to spend. On a build dominated by megamorphic calls or by one enormous method, the same policy can cost you code size and nothing else. The release also adds a hardening mechanism intended to stop attackers redirecting program execution to unexpected code locations [12], which is a security claim you cannot benchmark and should read the notes for.
The same roundup lists an initial implementation of a Jakarta Agentic AI specification in Azul Payara 7.3.0, so the specification process has now reached agents [15].
For the PEM work, the useful read is that the API surface has stopped moving. Three previews produced two visible edits, one to an interface name and one to a class kind [6][5], and after finalisation the next change to either would need a compatibility story rather than a preview flag.
