JEP 537 Proposes Vector API for Twelfth Incubation in JDK 27
The Java ecosystem's longest-running incubating API continues its journey toward finalization: JEP 537 (Vector API, Twelfth Incubator) has been elevated to "Proposed to Target" status for JDK 27, slated for General Availability in September 2026. The Vector API provides a standard mechanism for expressing SIMD (Single Instruction, Multiple Data) computations that compile reliably to optimal vector instructions on supported CPU architectures — AVX-512 on x86 and SVE on ARM.
After eleven incubation rounds spanning JDK 16 through JDK 26, the specification itself remains largely stable. The JEP notes no substantial implementation changes since JDK 25, which is intentional: the team is deliberately holding finalization until Project Valhalla's value types land and can be incorporated into the API surface. With JEP 401 (Value Classes) now formally targeted for JDK 27 preview, there is a reasonable chance the Vector API can graduate to a preview or even final status in JDK 28. Developers using the Vector API today can rely on a stable, high-performance incubating API while tracking the Valhalla dependency that is preventing a final release.
The practical implication is that any code written against the incubating API still requires --add-modules jdk.incubator.vector and will need minor source updates when the API is finalized, but the core computation model is not expected to change. Teams in scientific computing, signal processing, and data analytics who have been waiting on this feature should begin evaluating the current incubating API now rather than after GA.
Read more — OpenJDK
JEP 538 Proposes Finalization of PEM Encodings for Cryptographic Objects
JEP 538 (PEM Encodings of Cryptographic Objects) has been elevated to Candidate status with a proposal to finalize the feature in JDK 27, skipping a third preview round. This JEP introduces a standard Java API for reading and writing Privacy-Enhanced Mail (PEM) format files — the widely-used text-based encoding for cryptographic keys, certificates, and certificate revocation lists (CRLs). Previously, Java developers had to rely on third-party libraries like Bouncy Castle or write custom PEM parsing code when working with TLS infrastructure and PKI workflows.
The API, previewed in JDK 24 (JEP 470) and refined in JDK 26, provides PEMDecoder and PEMEncoder types that integrate naturally with the existing java.security and javax.security.cert APIs. Developers can now load a TLS certificate from a PEM file with a few lines of standard library code, and encode keys back to PEM without external dependencies. The feature also handles multi-PEM files (files containing multiple blocks) and supports PKCS#8, PKCS#1, X.509 SubjectPublicKeyInfo, and the common CERTIFICATE block types.
Elevating to Candidate rather than scheduling another preview signals the spec team's confidence that the API surface is stable enough for finalization. For security-conscious Java teams managing TLS certificates, configuring mutual TLS in Spring Boot or Quarkus, or building certificate management tooling, this API will materially simplify PEM handling without needing runtime dependencies.
Read more — OpenJDK
Azul Rebrands Payara Platform Community as "Azul Payara Community"
Azul Systems has officially rebranded the community edition of Payara Platform as Azul Payara Community, marking the first release under the new name with the May 2026 edition (version 7.2026.5). Azul acquired Payara in early 2025 and has been integrating Payara's Jakarta EE application server into its enterprise Java portfolio alongside Azul Zulu (OpenJDK distributions) and Azul Platform Prime (Zing JVM). The rebrand aligns Payara's naming convention with Azul's product family and signals continued investment in the community offering.
The May 2026 release delivers bug fixes, security patches, and dependency upgrades, with a notable internal migration: the JaccProviderCompatibilityStartup class has been refactored to replace the heritage Payara 6 JACC provider and policy configuration factory with the Eclipse Exousia DefaultPolicy and DefaultPolicyConfigurationFactory, improving alignment with the Jakarta EE 11 authorization specification. This migration removes a legacy compatibility layer that had been carried forward since Payara 6, reducing the surface area for authorization-related edge cases in Jakarta EE 11 deployments.
For teams running Jakarta EE workloads on Payara, the practical impact is minimal — the rebrand does not affect binary compatibility or configuration file formats. However, documentation, Docker image names, and Maven artifact coordinates may update over coming releases as Azul completes the integration. Enterprise customers considering a move to Payara 7 on Jakarta EE 11 should review the Exousia migration notes if they rely on custom JACC providers.
Read more — InfoQ
Links & Sources
You May Also Enjoy
