[
https://issues.apache.org/jira/browse/THRIFT-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated THRIFT-882:
---------------------------------
Attachment: thrift-882-v2.patch
I found this snazzy slice() method that makes an independent copy of all the
mark/position/etc state without copying the contents which saves me all the
trouble of simulating mark().
> deep copy of binary fields does not copy ByteBuffer characteristics
> (arrayOffset, position)
> -------------------------------------------------------------------------------------------
>
> Key: THRIFT-882
> URL: https://issues.apache.org/jira/browse/THRIFT-882
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.4
> Reporter: Mathias Herberts
> Assignee: Bryan Duxbury
> Fix For: 0.5
>
> Attachments: thrift-882-v2.patch, thrift-882.patch
>
>
> Generated objects have a constructor which does a deep copy of an existing
> instance.
> For binary fields, the deep copy is done like that:
> {code}
> if (other.isSetBinary_field()) {
> this.binary_field = ByteBuffer.wrap(new byte[other.binary_field.limit()
> - other.binary_field.arrayOffset()]);
> System.arraycopy(other.binary_field.array(),
> other.binary_field.arrayOffset(), binary_field.array(), 0,
> other.binary_field.limit() - other.binary_field.arrayOffset());
> }
> {code}
> This copies the backing array of the ByteBuffer but does not set the position
> correctly.
> In various protocol implementations, ByteBuffer instances are serialized by
> considering data between position and limit, this means that an object
> created from another object might lead to different serialized data (and thus
> a different deserialized value) in case a ByteBuffer has a non default
> position (which can happen since ByteBuffers can be set).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
