RFR 8025003: Base64 should be less strict with padding

[Xueming Shen]

On 11/13/2013 10:41 AM, Bill Shannon wrote:
>
>
>> The other thought is the charset API where a charset decoder can be configured
>> to ignore, replace or report then malformed or unmappable input. Having support
>> for all these actions is important for charset encoding/decoding but seems way
>> too much for Base64 where I think the API should be simple for the majority of
>> usages.
> We started this with a request for a strict/lenient option.  That may still be
> simpler than figuring out how to do strict decoding and report the error in a
> way that users of the API can ignore the error and provide as much data as
> possible.
>
>> In any case, it's not clear what we can do this late in the schedule. It might
>> be prudent to just fix the MIME decoder to throw IAE consistently and re-visit
>> the API support for a lenient decoder in JDK 9.
> When we started this conversation there was plenty of time to fix this.  :-(

The issue here is we disagree on the specification of what lenient should be and how the
API should look like.

Here is the proposed change to undo the "lenient padding handling for mime" change we
did earlier to leave the option open for a complete "lenient base64" in future release,
when we have a consensus

http://cr.openjdk.java.net/~sherman/base64_malformed2/webrev/

Alan, I still keep the decode(buf, buf) change on the table, as I feel it might be better than
the existing one. But I'm fine if you prefer to keep the existing IAE throwing behavior.

-Sherman