Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

[Mandy Chung]

On 3/19/2014 12:28 PM, Xueming Shen wrote:
> On 03/19/2014 11:37 AM, Mandy Chung wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8035807
>>
>> Webrev at:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
>>
>> This patch converts the last 2 references to 
>> sun.misc.BASE64Encoder/Decoder from the jdk repo with 
>> java.util.Base64.   We should also update the tests and I have filed 
>> JDK-8037873 for that.
>>
>> Thanks
>> Mandy
>
> The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76
> characters during encoding, and ignores/skip \r or \n when decoding. 
> The new
> Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it 
> never
> inserts line separator when output, and throws exception for any 
> non-base64-
> alphabet character, including \r and \n.
>
> The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs
> sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder
> is that the Base64 Mime decoder ignores/skips any non-base64-alphabet
> (including \r and \n), while sun.misc.BASE64Decoder appears to simply
> use the init value "-1" for any non-base64-alphabet character for 
> decoding.
>
> I'm not familiar with the use scenario of ldap's Obj class, so I'm not 
> sure if
> it matters (if it ever outputs/inputs > 76 character data, or even it 
> does,if
> the difference matters).
>

Thanks Sherman.

I believe both cases don't have the 76 characters constraint although it 
uses MIME type encoder/decoder previously unless Vinnie and Alan say 
otherwise.

> Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder()
> returns singleton, so the de/encoder cache might not be necessary.

Thanks.   It calls encode/decode in a loop and so I think keeping a 
local variable to avoid getting it multiple time seems reasonable.

Mandy