RFR 8025003: Base64 should be less strict with padding

[Alan Bateman]

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.

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).

-Alan.