RFR 8025003: Base64 should be less strict with padding

[Alan Bateman]

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.

-Alan.