RFR: 8189366: SocketInputStream.available() should check for eof

2017-10-26 Thread vyom tewari
Hi All, Please review the simple change below. Webrev   : http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html BugId  : https://bugs.openjdk.java.net/browse/JDK-8189366 Currently SocketInputStream.available() does not check for "eof" and simply delegate to the impl even when

Re: RFR: 8189366: SocketInputStream.available() should check for eof

2017-10-26 Thread Bernd Eckenfels
What is currently returned at the end of a stream? This looks like a dangerous thing to do, if a existing implementation only read when something is available it might never detect that it reached EOF. Gruss Bernd -- http://bernd.eckenfels.net From: net-dev on b

Re: RFR: 8189366: SocketInputStream.available() should check for eof

2017-10-26 Thread Martin Buchholz
Any change that fiddles with "available" is never simple! I confess to not understanding sockets, but intuitively they differ from files in that eof is a murky concept - there may not be any data from the other end of the socket right now, but who knows what's coming soon? What's the difference be

Re: RFR: 8189366: SocketInputStream.available() should check for eof

2017-10-26 Thread David Lloyd
On Thu, Oct 26, 2017 at 4:44 AM, Bernd Eckenfels wrote: > What is currently returned at the end of a stream? This looks like a > dangerous thing to do, if a existing implementation only read when something > is available it might never detect that it reached EOF. At present it ultimately delegate

Re: RFR: 8189366: SocketInputStream.available() should check for eof

2017-10-26 Thread vyom tewari
On Thursday 26 October 2017 03:14 PM, Bernd Eckenfels wrote: What is currently returned at the end of a stream? This looks like a dangerous thing to do, if a existing implementation only Currently it returns 0 at end of stream and  same as after change. As David pointed out that ultimately it