Review/comment needed for the new public java.util.Base64 class

Xueming Shen xueming.shen at
Tue Oct 30 01:51:01 UTC 2012

Ulf, my apology. Some how I missed your email.

We tried various prototypes for this simple utility class. See

The v4 might be close to the static constant approach you suggested. 
While It's hard
to draw a clear line on which one is better, we concluded that the 
proposed approach
provides the best balance among usability, readability and 
extensibility. For example,
the "get" approach allows us to hide the "singleton" choice to the 
implementation. It
provides a consistent interface "fixed" basic/url/mime type en/decoder 
and the configurable
floating length/linefeed encoder.


On 10/29/12 11:15 AM, Ulf Zibis wrote:
> Hi Sherman,
> can you give me a short answer please?
> -Ulf
> Am 23.10.2012 16:57, schrieb Ulf Zibis:
>> Am 23.10.2012 15:04, schrieb Alan Bateman:
>>> I'm not sure that getUrlEncoder is the most suitable name to get a 
>>> base64url encoder. The reason is that the method name makes it sound 
>>> like it returns a URLEncoder or or at least an encoder for HTML 
>>> forms. While more verbose, getBase64UrlEncoder is clear that it 
>>> returns a base64url encoder.
>> I'm wondering, why there are those get... methods at all.
>> Alternatively you could make the appropriate constructors and 
>> predifined static variants public. So one only should use:
>> Base64.Encoder encoder = new Base64.Encoder(...);
>> Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE;
>> No need for those looong method names.
>> -Ulf

More information about the core-libs-dev mailing list