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

[Xueming Shen]

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

We tried various prototypes for this simple utility class. See
http://cr.openjdk.java.net/~sherman/base64/

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.

-Sherman

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
>>
>>
>