Thanks Chris,
I updated the wording as Alan suggest to just make sure there is no doubt on
the behavior :-)
http://cr.openjdk.java.net/~sherman/8014217/webrev/
-Sherman
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.
-Chris
On 14 May 2013, at 20:32, Xueming Shen<xueming.s...@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.s...@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
