peter-lawrey
commented
11 years ago This is a fair point given the implementation for these methods is outlined in the documentation.
The reason behind changing the implementation was that readBytes() should be abel to read the same length of data written to by writeBytes() and readChars() should do the same. As for writeUTF/readUTF this was done to save space and it can support length of more than 65535 as it uses stop bit encoding rather than a fixed length field.
As this is potentially a breaking change for anyone using these features I will add the change to Chronicle 2.0 https://github.com/OpenHFT/Java-Chronicle and possibly back fill it into 1.8
If data is written/read from Excerpt in the exact same manner (e.g. writeUTF()... readUTF()), everything seems to work fine. However, if the writeUTF/Bytes/Chars() methods are used to write data and then a more general read(byte[]) is used to read the data, it cannot be properly 'decoded' using another DataInput. This is because AbstractExcerpt does not seem to adhere to the documentated behavior of DataOutput, as follows:
writeBytes() -- writes an extra length byte, which should not be included writeChars() -- writes an extra 2 length bytes, which should not be included writeUTF() -- only writes one length byte, instead of two
It seems to me that if Excerpt is to extend DataInput and DataOutput, it's implementation should be consistent with the documented behavior of these methods.