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

Xueming Shen xueming.shen at oracle.com
Wed Mar 19 19:28:52 UTC 2014

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

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

-Sherman

More information about the core-libs-dev mailing list