[
https://issues.apache.org/jira/browse/THRIFT-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907231#action_12907231
]
Bryan Duxbury commented on THRIFT-882:
--------------------------------------
I'm coming around to the idea of hiding the ByteBuffers a little. It wouldn't
make sense for us to hide them completely, since that would take away basically
all of the benefit.
I'm going to open another issue about this.
> 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.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.
