FileOutputStream.available() and pipe EOF

Basin Ilya basinilya at
Mon Feb 19 12:43:43 UTC 2018

>> 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" <basinilya at>
>>> À: "core-libs-dev" <core-libs-dev at>
>>> 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:
>>> 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?

More information about the core-libs-dev mailing list