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.
