Here is a first stab at fixing this issue.
http://cr.openjdk.java.net/~chegar/7014860/webrev.00/webrev/
-Chris.
On 07/21/11 09:42 AM, Jing LV wrote:
Hi,
Thank you Chris! Would you please send the link when you have some
progress?
于 2011-7-18 18:00, Chris Hegarty 写道:
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.
