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
