RFR 8025003: Base64 should be less strict with padding

[Bill Shannon]

Alan Bateman wrote on 11/14/2013 06:18 AM:
> On 13/11/2013 20:28, Xueming Shen wrote:
>>
>> Yes, the plan is to see what other implementations do.
> I think we've run out road on this for JDK 8. Even if we had agreement on
> dealing with corrupt input then there is little/no time to get feedback and do
> any further adjustments. Technically only showstopper API changes have been
> allowed since October so we have been on borrowed time anyway. Also we're coming
> up on RDP2 so we'd have to justify any changes as showstoppers.
> 
> So what you would think about just leaving it strict for JDK 8 and then continue
> the work to see how lenient support should be exposed in the API so that it can
> go into JDK 9 early. That would allow you to consider whether it to have a means
> to get a Decoder that will consume all sewage or just decode up to the point
> where invalid chars or undeflow is detected. Also it probably is a bit
> inconsistent to have only decode buffer method stop (as proposed) so that could
> be looked at too.
> 
> If you agree then there is a bit of clean-up to do with the changes for 8025003
> that were pushed but I think that can be justified.

Making it strict is fine, but right now it's half-lenient, and you need a way
to use/wrap the APIs to ignore the errors and provide as much data as possible.