JEP 135: Base64 Encoding & Decoding

AuthorAlan Bateman
OrganizationOracle
Created2011/11/11
Updated2013/1/14
TypeFeature
StateFunded
Componentcore/libs
ScopeSE
RFE4235519
Internal-refsOracle:A360:707502
Discussioncore dash libs dash dev at openjdk dot java dot net
EffortS
DurationS
Endorsed-byBrian Goetz
Funded-byOracle
Release8
TargetM6

Summary

Define a standard API for Base64 encoding and decoding.

Motivation

Base64 encoding schemes are frequently used to encode binary/octet sequences that are transmitted as textual data. It is commonly used by applications using Multipurpose Internal Mail Extensions (MIME), encoding passwords for HTTP headers, message digests, etc.

The JDK is long overdue a standard API for Base64 encoding and decoding. It has been frequently requested by developers for many years, many resorting to using JDK private and unsupported classes such as sun.misc.BASE64Encoder and sun.misc.BASE64Decoder.

The JDK itself has several internal implementations: java.util.prefs.Base64, com.sun.org.apache.xml.internal.security.utils.Base64, and com.sun.net.httpserver.Base64 to name a few. A standard API would allow these sorts of implementations to be retired.

Description

Define a simple API, probably in java.util, for Base64 encoding and decoding.

The API must clearly specify the Base64 encoding scheme that is implements, probably the Base64 Content-Transfer-Encoding specified by RFC 1521.

The API should support common cases, such as encoding binary data in a byte array or read from an input stream, and decoding strings to a byte array or ByteBuffer.

Existing usages and implementations of Base64 in the JDK should be examined for opportunities to replace and use the new API.

Testing

This API will require new unit tests that will be developed along with the implementation. New functional tests would be useful too.

Impact