The read(byte[]) method in ByteSource was designed to behave like readFully in DataInputStream, i.e. fail when trying to read more data than available. For example the Blink codec relies on this behaviour.
The read(byte[]) method in InputStream is designed to read as much as possible, i.e. a "try read". The wrapper ByteSourceInputStream copies the behaviour from ByteSource to InputStream, and apparently this is not OK. For example the JSON codec (Jackson behind the scenes) relies on the "try read" behaviour to fill an internal parse buffer from the InputStream. This will fail whenever the internal parse buffer is larger than the remaining data, i.e. in most cases.
The ByteSourceInputStream wrapper is not easily fixed, since there is no "tryRead" in ByteSource or any way to find out how many remaining bytes there are.
I think an API change in ByteSource is hard to avoid, and hence this will likely be a major version bump. For example, rename existing read(byte[]) into readFully and add a new "try" read(byte[]) with InputStream semantics, or add a int remaining() or add tryRead(byte[]). All implementations of ByteSource will break...
If you need a failing test case in msgcodec-json to illustrate this, let me know.
The
read(byte[])method inByteSourcewas designed to behave likereadFullyinDataInputStream, i.e. fail when trying to read more data than available. For example the Blink codec relies on this behaviour.The
read(byte[])method inInputStreamis designed to read as much as possible, i.e. a "try read". The wrapperByteSourceInputStreamcopies the behaviour fromByteSourcetoInputStream, and apparently this is not OK. For example the JSON codec (Jackson behind the scenes) relies on the "try read" behaviour to fill an internal parse buffer from theInputStream. This will fail whenever the internal parse buffer is larger than the remaining data, i.e. in most cases.The
ByteSourceInputStreamwrapper is not easily fixed, since there is no "tryRead" inByteSourceor any way to find out how many remaining bytes there are.I think an API change in ByteSource is hard to avoid, and hence this will likely be a major version bump. For example, rename existing
read(byte[])intoreadFullyand add a new "try"read(byte[])withInputStreamsemantics, or add aint remaining()or addtryRead(byte[]). All implementations ofByteSourcewill break...If you need a failing test case in msgcodec-json to illustrate this, let me know.