[Java] big/little Endian issue?
hrstoyanov opened this issue · 5 comments
SBE message schema accepts byteOrder attribute and applies it for everything in it. Can one override the byte order at the type level? For example, I would have expected that in the below case, position and length methods in the generated encoder/decoder will be using Big Endian byte order, but seems like the schema default of Little Endian was used?
<sbe:messageSchema
description="MS SQL TDS schema."
id="1"
version="1"
semanticVersion="5.2"
byteOrder="littleEndian">
<types>
<composite name="preLoginOption" description="Pre-login request option">
...
<type name="position" primitiveType="uint16" byteOrder="bigEndian"/>
<type name="length" primitiveType="uint16" byteOrder="bigEndian"/>
</composite>
</types>
...
Generated code:
//Encoder
public PreLoginOptionEncoder position(final int value)
{
buffer.putShort(offset + 1, (short)value, java.nio.ByteOrder.LITTLE_ENDIAN);
return this;
}
...
//Decoder
public int position()
{
return (buffer.getShort(offset + 1, java.nio.ByteOrder.LITTLE_ENDIAN) & 0xFFFF);
}
The SBE standard does not support this.
... Ok, but:
a. do you find the above request reasonable , and if so :
b. Can I contribute a PR for it in this project ?
c. .. or Do I have to convince the "SBE protocol owners" first, and then submit a PR here?
That would not be within the SBE 1.0 final specification. Engaging with the standards body for a future version of the standard would be the way to approach this.
@mjpt777 I am not winning hearts and minds in the SBE group for this change, but I am still up for contributing a patch in this project for flexible BE/LE encoding, if allowed . One cool way of doing this is to allow the functionality under a tool switch, so SBE will remain compliant by default. What do you think?
Adding a byteOrder attribute will not pass validation when the XSD is applied. SBE tool could be modified to do this in a non-standard way as an option. However I not minded to support or even consider going against the standard without good reason from a paying support customer.