A DESCRIPTION OF THE PROBLEM :
My proposal is to canonicalize implementation of IO in java.io package with java.nio.
The fact that both of these systems are designed for the same purpose but use different native routines introduces problems...
It's difficult to find out whats wrong with the code that reads from process' stdin when latter is a pipe. Seemingly, call to write to a stream was getting stuck in ntdll in `ZwWriteFile`.
Turns out, `FileInputStream::avail;able0` calls `handleAvailable` which checks for `FILE_TYPE_CHAR`, `FILE_TYPE_PIPE` and `FILE_TYPE_DISK`. However, `FileDispatcherImpl` used in `java.nio` only handles `FILE_TYPE_DISK` thus returning 0 for every `InputStream::available` call.
I understand from the documentation that said method is an estimate and may always return 0, however one would expect for both to result in the same behavior for the same type of a file descriptor, given that these methods implemented natively in the JDK.
There have been reports regarding the same issues in the past months.
There may be some other methods that have the same problems, but I have not stumbled upon such at this point...

https://github.com/openjdk/jdk/blob/6b994cd8ccba4f5d0199cb2925f0a6b5450ac115/src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c#L398
vs
https://github.com/openjdk/jdk/blob/6b994cd8ccba4f5d0199cb2925f0a6b5450ac115/src/java.base/windows/native/libjava/io_util_md.c#L294

Similar reports:
https://bugs.openjdk.org/browse/JDK-8341666 (FileInputStream doesn't support readAllBytes() or readNBytes(int) on pseudo devices)
https://bugs.openjdk.org/browse/JDK-8233451 ((fs) Files.newInputStream() cannot be used with character special files)