RFR 8025003: Base64 should be less strict with padding
bill.shannon at oracle.com
Fri Nov 15 18:17:43 UTC 2013
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.
More information about the core-libs-dev