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

[Xueming Shen]

There is no plan yet. The sun.misc.BASE64En/Decoder should already 
trigger a compiler
warning for it's a sun private API. @Deprecated annotation might be a 
good fit.

-Sherman

On 10/10/12 1:40 PM, Joe Darcy wrote:
> Hello,
>
> On 10/10/2012 1:03 PM, Iris Clark wrote:
>> Hi, Sherman.
>>
>> I'm glad to see this coming in.  As you said, long overdue.
>>
>> I'm curious.  What are the plans are to encourage migration from the 
>> JDK private and unsupported sun.misc.BASE64{En,DE}coder classes?  
>> Compile-time warning?  Documentation?  Something else?
>
> On that point, sun.misc.BASE64{En,DE}coder may present a fine 
> opportunity to use the @Deprecated annotation...
>
> -Joe
>
>>
>> Thanks,
>> iris
>>
>> -----Original Message-----
>> From: Xueming Shen
>> Sent: Wednesday, October 10, 2012 10:55 AM
>> To: core-libs-dev
>> Subject: Review/comment needed for the new public java.util.Base64 class
>>
>>
>> A standard/public API for Base64 encoding and decoding has been long 
>> overdue. JDK8  has a JEP [1] for this particular request.
>>
>> Here is the draft proposal to add a public Base64 utility class for 
>> JDK8.
>>
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> This class basically provides 4 variants of Base64 encoding scheme,
>>
>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace 
>> "+" and
>>       "/" for the mapping
>> (3) the default MIME style, as in RFC 2045 (and its earlier 
>> versions), which uses
>>       "standard" base64 mapping, a 76 characters per line limit and 
>> uses crlf pair
>>        \r\n for line break.
>> (4) an extend-able MIME base64, with the char-per-line and the line
>> separator(s)
>>        specified by developer.
>>
>> The encoder/decoder now provides encoding and decoding for byte[], 
>> String, ByteBuffer and a pair of "EncoderInputStream" and 
>> "DecoderOutputStrream", which we believe/hope should satisfy most of 
>> the common use cases.
>> Additional
>> method(s) can be added if strongly desired.
>>
>> We tried couple slightly different styles of design for such this 
>> "simple" utility class [2].  We kinda concluded that the version 
>> proposed probably provides the best balance among readability, 
>> usability and extensibility.
>>
>> Please help review and comment on the API and implementation.
>>
>> Thanks!
>> -Sherman
>>
>> [1] http://openjdk.java.net/jeps/135
>> [2] http://cr.openjdk.java.net/~sherman/base64/
>