Final

If you have ever had to read a private key or a certificate from a file in Java, you know the pain. You probably wrote a utility method that manually stripped out the —–BEGIN… header, removed newlines, and performed a Base64 decode, only to feed it into a KeyFactory. It felt like hacky string manipulation for something that should be standard.

The Gist: This JEP, and its predecessor JEP 470 in Java 25, introduces a standardized, easy-to-use API for encoding and decoding PEM (Privacy-Enhanced Mail) files. Instead of using third-party libraries (like Bouncy Castle) or writing brittle string replacement code, you can now parse keys and certificates natively.

What is PEM? (And Why Do We Use It?) PEM stands for Privacy-Enhanced Mail. It is a de facto standard for storing cryptographic objects (like SSL certificates, public keys, and private keys) as plain text files. Computers prefer processing cryptography in binary formats (like DER - Distinguished Encoding Rules). However, binary data is hard to copy-paste into an email body or a config file without it getting corrupted. PEM solves this by translating that binary data into safe, readable text.

The Concept: The “PEM Sandwich” Final

Code Example: Here is how simple it is to read an encrypted private key now:

1
2
3
4
5

// The Old Way required over a dozen lines of string manipulation and KeyFactory logic.
// The Java 26 Way:
PrivateKey key = PEMDecoder.of()
.withDecryption("my-secret-password".toCharArray())
.decode(pemFileString, PrivateKey.class);

What’s new in Java 26 (Second Preview)? This feature first appeared in JDK 25, but it has been refined for Java 26:

  • Renaming: The class PEMRecord is now simply PEM.
  • Better Encryption Support: You can now easily encrypt and decrypt KeyPair and PKCS8EncodedKeySpec objects directly.
  • Simpler Methods: Methods like encryptKey have been renamed to just encrypt for cleaner code.