>> or instead of relying on an undocumented behaviour Fine. Isn't the goal of Java to behave equally on various OSes? If there's a difference, we should adopt the best variant AND document it. And in this case it is to throw an exception on EOF. I don't know about Solaris, but on Windows it's a matter of what to do when PeekNamedPipe() returns EOF. We can even add a JVM option to restore the old behavior, like it was with String.split().
On 11.02.2018 0:35, Basin Ilya wrote: > Unfortunately, read() is > 1) uninterruptilbe > 2) Unlike sockets, close() or even Thread.stop() won't cancel a read > pipe operation on Windows > > > 11.02.2018 0:27, Remi Forax пишет: >> Hi Basin, >> or instead of relying on an undocumented behaviour, you can use any >> overloads of read(), if it returns -1, it's the ends of the stream. >> >> cheers, >> Rémi >> >> ----- Mail original ----- >>> De: "Basin Ilya" <basini...@gmail.com> >>> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> >>> Envoyé: Samedi 10 Février 2018 22:15:18 >>> Objet: FileOutputStream.available() and pipe EOF >> >>> Hi list. >>> >>> My question relates to streams returned by >>> java.lang.Process.getInputStream() >>> >>> On Linux calling available() after the other side of the pipe was closed >>> will throw: >>> >>> java.io.IOException: Stream Closed >>> >>> This is very handy, because you can distinguish EOF and a pause in >>> transmission. >>> >>> On Windows same Oracle JDK version 1.8.0_161 behaves in a traditional >>> manner and available() returns 0 in both cases. Will this ever change?
