Review/comment needed for the new public java.util.Base64 class
xueming.shen at oracle.com
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
provides the best balance among usability, readability and
extensibility. For example,
the "get" approach allows us to hide the "singleton" choice to the
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?
> 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.
More information about the core-libs-dev