Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Java] Generate bulk put/get/wrap methods for fixed-length data (uint8 array) #819

Merged
merged 2 commits into from Oct 23, 2020

Conversation

AndreyNudko
Copy link
Contributor

There are some cases when message contains byte array of fixed size which is not an ASCII string - e.g. hmac signatures. Declaring them as fixed-size uint8 array currently generates only generic array accessor to put/get one element at a time. Declaring them as strings generate bulk put/get methods which accept byte[], but string semantics - e.g. charset - do not really apply to the field.
This PR adds bulk get/put methods for fixed-length data (described in the "Fixed-length data" section of the spec).

Encoder
public void putData(byte[] buffer, int offset, int length);
public void putData(DirectBuffer buffer, int offset, int length);
These methods behave like var-length counterparts, but pad smaller payloads to the required length with zeros. I couldn't find anything in the spec on the padding, but this looks like least-surprising behaviour - e.g. the following hypothetical code would behave as if new buffer is allocated every time, even if it's in fact reused

  int actualLength = fillData(data);
  encoder.putData(data, 0, actualLength)

Expected typical usage is actually that caller will provide all bytes.

Decoder
public int getData(byte[] buffer, int offset, int length);
public int getData(MutableDirectByteBuffer buffer, int offset, int length);
public void wrapData(DirectByteBuffer buffer);
These methods behave similar to var-length counterparts:

  • read min of the provided and actual length
  • getData will return 0 when decoding older version of the message w/o the field
  • wrapData will result in empty buffer when decoding older version

It also seems like there was a bug when generated wrapData() did not properly handled older versions (missing return) - this should be fixed.

@mjpt777
Copy link
Contributor

mjpt777 commented Oct 23, 2020

The C++ tests need to be updated as you changed a common schema.

@AndreyNudko
Copy link
Contributor Author

Fixing those C++ tests turned to be quite a lot of work - I ended up reverting common schema changes and introducing separate java test based on extension-schema.xml

@mjpt777 mjpt777 merged commit dd7f084 into real-logic:master Oct 23, 2020
mjpt777 added a commit that referenced this pull request Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants