[13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing

[Nishit Jain]

Thanks Roger, Naoto for reviewingthe changes

Updated the webrev
- Used ByteBuffer.wrap(inputBytes) instead of ByteBuffer.allocate(size)
- Added Decoder.decode(ByteBuffer)method test. (line 58)

http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.01/

Regards,
Nishit Jain
On 05-02-2019 00:03, Naoto Sato wrote:
> +1
>
> Naoto
>
> On 2/4/19 10:18 AM, Roger Riggs wrote:
>> Hi Nishit,
>>
>> Looks fine.
>>
>> Thanks for fixing the test and improving the implementation.
>>
>> The test could save one 2G allocation by using 
>> ByteBuffer.wrap(inputBytes)
>> instead of ByteBuffer.allocate(size).
>>
>> Thanks, Roger
>>
>>
>>
>> On 02/04/2019 10:31 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the below fix for 8217969 and 8218265
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217969
>>>      https://bugs.openjdk.java.net/browse/JDK-8218265
>>>
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/
>>>
>>> Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw 
>>> OOME when an integer value overflows, which is an intermediate 
>>> value, not the final value, the final value is always less than 
>>> Integer.MAX_VALUE. Also, the test case written for 8210583, fails on 
>>> certain platforms and throws "OutOfMemoryError: Requested array size 
>>> exceeds VM limit ", due to the array size of length 
>>> Integer.MAX_VALUE - 2.
>>>
>>> Fix: Handled the integer overflow by storing the intermediate value 
>>> as "long" and converting the final value as integer. Also, updating 
>>> the test case input array length to Integer.MAX_VALUE - 8, since 
>>> MAX_VALUE - 2 was used only to test the overflow condition in 
>>> Decoder.decode() which is no longer there.
>>>
>>> Regards,
>>> Nishit Jain
>>