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.
