RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit
xueming.shen at oracle.com
Tue May 14 20:00:28 UTC 2013
I updated the wording as Alan suggest to just make sure there is no doubt on
the behavior :-)
On 05/14/2013 12:46 PM, Chris Hegarty wrote:
> 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.
> 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."?
>> On 05/14/2013 12:25 PM, Chris Hegarty wrote:
>>> Is there a conflict between the spec and implement? IOE versus IAE?
>>> On 14 May 2013, at 19:50, Xueming Shen<xueming.shen at oracle.com> wrote:
>>>> 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
>>>> 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.
More information about the core-libs-dev