FSTObjectInput#read() violates the ObjectInput contract

[rdicroce]

FSTObjectInput#read() currently does this:

return getCodec().readFByte();

Java sign extends the value when performing a widening conversion, from byte to int in this case, which means that read() is returning a signed int.

The Javadoc for ObjectInput#read() implies that the return value should be unsigned. It says the method should return "the byte read, or -1 if the end of the stream is reached". If the value were supposed to be signed, then -1 would be a valid value and could not be used as a sentinel.

So read() should do this instead, to make the value unsigned:

return getCodec().readFByte() & 0xFF;

[RuedigerMoeller]

Will checkback if the wrong behaviour is present for all codecs. Thanks for the report :-)

[RuedigerMoeller]

As I avoid use of streams in most IO code, stream handling/compliance/support in fst is not too well. The need to walk through significant length of code (wrapped streams) to just read a single byte is one reason why stock JDK serialization perfoms slow.
Fixed the issue, however it could be expected there are other issues regarding iostreams compliance.
Thx for reporting.

fixed with 2.24