this is wrong, as it indicates that the stream has reached EOF but it simply means the buffer is empty. See also the javadoc here:
Returns an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking, which may be 0, or 0 when end of stream is detected.
So in case of 0 return value one can simply not tell anything, so at best one can return EMPTY here.
But looking at the code I don't see how this ever is useful in the parsing here, as even if the buffer is empty now, all one can do is to wait for one byte so blocking I/O seems the only option here.
it assumes EOF also when the read byte is == 0, even though it should not happen and is an error in the http stream, a zero byte can be read from a stream and is not an EOF!
org.takes.rq.RqLive.data(InputStream, Opt<Integer>, boolean)has the following codehttps://github.com/yegor256/takes/blob/20467cf2729566461ad4c7fe7123cf4ea57c51ed/src/main/java/org/takes/rq/RqLive.java#L183-L185
this is wrong, as it indicates that the stream has reached EOF but it simply means the buffer is empty. See also the javadoc here:
So in case of 0 return value one can simply not tell anything, so at best one can return EMPTY here.
But looking at the code I don't see how this ever is useful in the parsing here, as even if the buffer is empty now, all one can do is to wait for one byte so blocking I/O seems the only option here.
Another pitfall is that here: https://github.com/yegor256/takes/blob/20467cf2729566461ad4c7fe7123cf4ea57c51ed/src/main/java/org/takes/rq/RqLive.java#L73
it assumes EOF also when the read byte is == 0, even though it should not happen and is an error in the http stream, a zero byte can be read from a stream and is not an EOF!