Hello Trusin, you pointed out some very interesting thoughts. In fact it will result in unexpected behaviour, when common stream wrappers are used on a non-blocking stream without proper orevious checking. I see two possibilities: Using streams that emulate a blocking mode and throw some sort of WouldBlockException if blocking is disabled (by default) or rolling out our own stream-like version of a real non-blocking stream.
I see the following general advantages of streams over buffers: - Very easy to use because the stream API is very clear and known by most developers - Automatic dispose of already consumed underlying buffers - No exposure of unnecessary low level functionality like flip(), limit(), iterate over buffers etc. - Possibility to reuse the same stream when some new data is available so that protocol developers don`t need to handle buffering on their own (just leave unused bytes inside the stream and process them later when more data is available / the decoder is notified) - Zero-Copy without a need for users to know (much) about the underlying buffer architecture (just append buffers to a stream) - Not an advantage, but also: Possibility for random access by using mark(), skip() and reset() in sequence, maybe with an additional moveTo() relative to the marked position implemented by combining the previous three - however, random access is not required for most protocols - Ability to use common wrappers for OutputStream - Ability to use common wrappers for InputStream (but only if data availability is previously checkable/checked to be valid) Disadvantages of extending java.io.InputStream: - Unexpected behaviour when using common wrappers on a stream in non-blocking mode with no proper previous checking of available data So, do we really need to extend InputStream / use common input wrappers? Maybe it makes sence to roll out our own stream-like real non-blocking inputstream that cannot be used with common input wrappers but implementing all the required put- and get-Methods. However, I still think that a stream-like implementation of the whole buffer thing makes it much easier for the end user to understand and use. regards Daniel
