FileOutputStream.available() and pipe EOF

[Basin Ilya]

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