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