Thanks Mark for looking into this issue.
The change itself looks fine. Though I'm a little concerned whether
the performance cost (need to do an additional linemax > 0 check
inside the 'while" loop) is really worth it. Maybe an alternative is
to simply set the linemax to -1 if it's 0? such as
public static Encoder getEncoder(int lineLength, byte[] lineSeparator) {
Objects.requireNonNull(lineSeparator);
int[] base64 = Decoder.fromBase64;
for (byte b : lineSeparator) {
if (base64[b & 0xff] != -1)
throw new IllegalArgumentException(
"Illegal base64 line separator character 0x" +
Integer.toString(b, 16));
}
if (lineLength == 0)
lineLength = -1;
return new Encoder(false, lineSeparator, lineLength >> 2 << 2);
}
And given it actually become a "normal" RFC4648 if the lineLength <=0, maybe
we should simply eliminate this "option" by changing the spec to say "throw
IAE if lineLength <=0", go use BAse64.getEncoder() if lineSeparator is not
needed.
-Sherman
On 03/27/2013 09:01 AM, Mark Sheppard wrote:
Hi,
please oblige and review the webrev below as a fix for the issue raised in
JDK-8007799
http://cr.openjdk.java.net/~msheppar/8007799/webrev.00/
Description:
"Specification for the method
java.util.Base64.getEncoder(int lineLength, byte[] lineSeparator)
says:
Parameters:
lineLength - the length of each output line (rounded down to nearest multiple
of 4). If lineLength <= 0 the output will not be separated in lines
However if a zero line length is specified encoding methods wrap() and
encode(ByteBuffer src, ByteBuffer dst, int bytesOut) return encoded string which
starts from the given line separator. "
the patch adds a check for linemax > 0 whenever a line separator might be
added, and adds an new test case.
regards
Mark
