RFR 8025003: Base64 should be less strict with padding

[Bill Shannon]

Alan Bateman wrote on 11/15/13 04:21:
> On 14/11/2013 23:27, Bill Shannon wrote:
>> :
>> I'd prefer that all variants of the API report the error in a way that allows
>> the users of the API to ignore the error, access the data that caused the error,
>> and supply replacement data if desired.
>>
>> For most of the APIs, decoding as much data as possible and throwing an
>> exception with details about how much has been decoded and where the error
>> was detected would be best.  I understand that designing this and getting
>> it right might exceed what you can do in this release.  In that case, just
>> throw an exception with no details, and we can figure out what details to
>> provide later.  Returning a negative number is kind of a hack, and unlike
>> most other APIs.  Plus, if we decide we need to return two numbers (e.g.,
>> input and output positions), there's no way to extend it.
> This is where the methods that decode buffers are useful as the input and output
> buffer positions can be advanced to reflect the input that had been decoded
> successfully. So even when strict then it should be possible (although maybe
> ugly due to the exception) then you at least know where the corruption starts
> and you have the bytes that have been successfully decoded.

And hopefully the same for the stream-based version.

> As regards adding API support for ignore or replace then I think this will need
> to be something to consider for the future (it's just too late for JDK 8).

Right, as long as I can wrap the strict API to provide this effect,
that's good enough for now.