RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit

[Chris Hegarty]

Thanks for the explanation Sherman. No further changes required. What you have is fine.

My question was provoked because the  details in the email seemed at odds with the changes.

-Chris

On 14 May 2013, at 20:32, Xueming Shen <xueming.shen at oracle.com> wrote:

> It has been discussed before that the IOE is preferred in case of the wrapped
> decoding stream. The spec of wrap() does mention that "IOE when reading
> bytes that can not be decoded".
> 
> So personally I feel it has been "covered", but if preferred, it can go further as
> 
> "If there is padding character present in the final unit, the correct number of padding
> character(s) must be present, otherwise IllegalArgumentException (or IOException in case
> of decoding from the wrapped base64 stream), is thrown during decoding."?
> 
> -Sherman
> 
> On 05/14/2013 12:25 PM, Chris Hegarty wrote:
>> Is there a conflict between the spec and implement? IOE versus IAE?
>> 
>> -Chris
>> 
>> On 14 May 2013, at 19:50, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> 
>>> Hi,
>>> 
>>> Please help review the change for handling a "malformed base64 stream" corner case.
>>> The latest spec has been updated/clarified as
>>> 
>>> "If there is padding character present in the final unit, the correct number of padding
>>> character(s) must be present, otherwise IllegalArgumentException is thrown during
>>> decoding."
>>> 
>>> But the stream decoding implementation has not been updated accordingly. The change
>>> is to throw the IOE if the padding character "=" is missing from the xx== pattern.
>>> 
>>> http://cr.openjdk.java.net/~sherman/8014217/webrev/
>>> 
>>> Thanks!
>>> Sherman
>