A common way to exchange keys or certificates, particularly when a squishy human is involved, is to use the text-based PEM format. The JDK comes with all the building blocks to turn these texts into cryptographic objects and vice versa but that required a decent amount of custom code.

Starting in JDK 25, Java previewed an API that makes these transformation much easier. First, you create a `PEMEncoder`, then call `encode` with an instance of the new interface `DEREncodable`, which types like `AsymmetricKey` and `X509Certificate` extend. And then you can then store or send the resulting byte array or string. On the other end, a `PEMDecoder` instance can decode from a string or input stream and return a `DEREncodable` instance that you can pattern match over. Alternatively, you can specify to `decode` what exact type you expect and then either get that back or an exception. You can also encrypt these objects and configure an alternative cryptographic provider.

In JDK 26, JEP 524 previews the API for a second time with a few changes, most notably the added support for `KeyPair` and `PKCS8EncodedKeySpec`.

JEP 524: https://openjdk.org/jeps/524
JDK 26: JDK 26: http://jdk.java.net/26

Come to *JavaOne 2026* in Redwood City (California, USA), March 17th-19th, and *get 100$ off* with code *J12026YTS* : https://www.oracle.com/javaone/

Java (Official Oracle)

Java 26 (JEP 524) previews an updated PEM encoding/decoding API that simplifies working with cryptographic objects like keys and certificates. A PEMEncoder can encode any DEREncodable (such as AsymmetricKey or X509Certificate) to a byte array or string, while a PEMDecoder can decode from a string or input stream with optional type-safe decoding. The JDK 26 iteration adds support for KeyPair and PKCS8EncodedKeySpec. The API also supports encrypting objects and configuring alternative cryptographic providers.

En- & Decoding PEM Texts in #Java 26 #IJN #Coding