InputStream.read(bytes)的文档说"；此方法会阻塞，直到输入数据可用、检测到文件结尾或引发异常为止">
然而，java.io.FileInputStream扩展了java.io.InputStream并且FileInputStream.read(bytes)的文档没有这样的保证：
* Reads up to {@code b.length} bytes of data from this input
* stream into an array of bytes. This method blocks until some input
* is available.
在实践中，FileInputStream确实可以在所有输入可用之前返回，因此文档和实现似乎都不遵循InputStream的约定。
这是个虫子吗？这是一个已知的bug吗？
更新：澄清：System.in是FileInputStream。我看到System.in.read(buf)返回一个非零int，它既不是所有字节，也不是-1。如果我使用System.in.readNBytes(buf, 0, theNumberOfBytesIAmExpecting)，那么我会得到发送方正在发送的所有字节。
这不是违反合同，因此不是bug。
CCD_ 12的文档指定它阻塞直到"0"；输入数据可用；这与"；所有的输入都是可用的">
如果你指的是"；文件末尾"；方面，继续阅读指定的FileInputStream.read的Javadoc
读取到缓冲区的总字节数，或-1，如果由于到达文件末尾而没有更多数据
我认为情况更微妙，-InputStream.read(byte[] b)只是委托给InputStream.read(byte[] b, int off, int len)
对于read(byte[] b, int off, int len)来说，合同/承诺似乎被打破了(或者至少不同(。
对于InputStream.read(byte[] b, int off, int len)，文件说明：
此方法的默认实现会阻塞，直到读取了请求的输入数据量len、检测到文件结尾或引发异常为止。鼓励子类提供这种方法的更有效的实现。
(它是这样实现的：-总是读取请求的数据量(
对于FileInputStream.read(byte[] b, int off, int len)，没有这样的承诺(实施可能不会读取所有请求的金额(。
许多其他高级方法委托给read(byte[] b, int off, int len)，我认为至少对于这种方法，InputStream(读取请求的量或直到蒸汽结束(的承诺在FileInputStream中被打破了，这会造成混乱。