On 07/18/11 09:09 AM, Jing LV wrote:
Hi Chris, Alan,
Thanks for reply. I am looking for a conclusion and solution for this
issue. If I understand correctly, it'd fix the spec rather than fix the
code?
The current plan of record is to clarify the spec to indicate that
available will return 0 after shutdownInput is invoked. Then change the
implementation to do just this.
I'll send out a webrev soon.
-Chris.
δΊ 2011-7-14 17:00, Chris Hegarty ει:
On 07/14/11 09:36 AM, Alan Bateman wrote:
Chris Hegarty wrote:
:
I can't see that anyone could be depending on the fact the available()
would return > 0 after shutdownInput(), given that subsequent reads
will always return -1. I just can't see why anyone would require this,
but maybe I'm missing something.
You're probably right, and it's just the concern that there may be code
that won't now read and see the end-of-stream. The other concern is that
Yes, interesting point. I think this may be less of a concern though.
Can anyone even depend on this today, i.e. use available to determine
when to read and expect to reach eof? I don't think so because they
may just happen to read the exact amount of data being sent and
available will always return 0.
Also, it does seems unlikely that this change would surprise too may
people, they are calling shutdownInput explicitly on the socket.
Let me put together a webrev and see the extent of the changes.
-Chris.
we don't know how custom SocketImpls might behave. Overall the risk does
seem low.
-Alan.
