[13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException

Naoto Sato naoto.sato at oracle.com
Thu Jan 17 21:14:35 UTC 2019

I agree with 'withOutputParam' comment. It does seem to require some 
explanation. Same for the newly introduced return value -1.

The test:
   46         // A separate output array is not required, as it is not 
used and
   47         // the exception is thrown beforehand while calculating 
the size
   48         // of the encoded bytes using input array

This seems to make an assumption on the implementation. Test should not 
depend on the internal impl.


On 1/17/19 8:14 AM, Roger Riggs wrote:
> Hi Nishit,
> 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.
> java/util/Base64.java:
> 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.
> Thanks, Roger
> On 01/17/2019 02:07 AM, Nishit Jain wrote:
>> Hi,
>> 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.
>> Regards,
>> Nishit Jain

More information about the core-libs-dev mailing list