RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that unexpectedly inserts line separator when using some of the encoding methods

Iris Clark iris.clark at oracle.com
Fri Apr 26 15:24:26 UTC 2013


> The copyright should be "2012, 2013,"?

I agree.  The copyright year should be updated as Sherman indicated.

iris

-----Original Message-----
From: Xueming Shen 
Sent: Friday, April 26, 2013 8:05 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that unexpectedly inserts line separator when using some of the encoding methods

On 4/26/13 6:55 AM, Mark Sheppard wrote:
> Hi,
>    please oblige with a review of the fix for the issue JDK-8007799 as 
> shown in the webrev
> below:
>
> http://cr.openjdk.java.net/~msheppar/8007799/webrev.01/
>
> This fix takes into account the feedback from the initial review and 
> condenses the solution to a check on the line length in the
> getEncoder() method,
> which will return an RFC4648 base64 encoder when the line length <=0.
> The RFC4648 base64 encoder provides the required semantics specified 
> in the API.
>
> regards
> Mark

Hi Mark,

I think we may still want to non-null-check lineSeparator and its content first and then the lineLength <=0 (move ln#135-137 down just before ln#145), otherwise it may fail some tck tests. I understand the lineÍeparator will not be used in this scenario so the check may look like wasting of time, but I guess it would be better to still throw the NPE or IAE if they are null or having illegal bytes in it.

The copyright should be "2012, 2013,"?

-Sherman





More information about the core-libs-dev mailing list