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

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

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

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

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

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

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

On 14/05/2013 20:32, Xueming Shen 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

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

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

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

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