RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException
Roger.Riggs at oracle.com
Thu Jan 17 16:14:25 UTC 2019
In the test, there are a couple of RuntimeExceptions with messages that
start with "As expected"...
That's counter intuitive, that a failure of the test is reported with a
message saying, its normal!
I would use a message like: "XXException should have been thrown..."
The size of Integer.MAX_VALUE - 2 is implementation specific,
I think more typically max -8 is used to get the biggest allocation.
Lines 335-342: This optimization is not mentioned in the bug report and
should be a separate review.
245, 686: in outLength(), the 2nd parameter would be easier to understand
as 'throwOOME', meaning to throw OOM if length is too large.
The 'withOutputParam' only has any meaning in the context of the caller.
And even for the private method write the javadoc describing the behavior.
It also makes the call sites clearer, the argument will be true to throw.
On 01/17/2019 02:07 AM, Nishit Jain wrote:
> Please review the fix for 8210583
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210583
> Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8215633
> Issue: Base64.Encoder.encode and Base64.Decoder.decode methods
> incorrectly throw unspecified exception e.g.
> NegativeArraySizeException, when the input byte array size is too
> large such that the calculated output byte size goes beyond the
> max-integer boundary and wraps around.
> Fix: Throw an OutOfMemoryError if the output byte array/buffer or
> memory can not be allocated. There is an unrelated change in
> encodeToString(byte) where a string instance is created using
> JavaLangAccess.newStringNoRepl(byte, ISO_8859_1)instead of string
> constructor, to save memory.
> Nishit Jain
More information about the core-libs-dev