[
https://issues.apache.org/jira/browse/THRIFT-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695577#comment-15695577
]
Fabrice Trillaud commented on THRIFT-3985:
------------------------------------------
It might be argued that that's the way ByteBuffer works, and that it's up to
the developer to take it into account will reading the buffers afterwards. But
it seems rather unnecessarily complicated and error-prone. It also implies that
the deserialized object will contain much more data than needed, thus
potentially using too much memory.
> Bad use of ByteBuffer.wrap with buffered transport in Binary and Compact
> protocol
> ---------------------------------------------------------------------------------
>
> Key: THRIFT-3985
> URL: https://issues.apache.org/jira/browse/THRIFT-3985
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
> Affects Versions: 0.9.3
> Reporter: Fabrice Trillaud
>
> It seems that ByteBuffer.wrap is not used correctly in TBinaryProtocol and
> TCompactProtocol in the readBinary methods.
> It it used as if the wrap(buf,offset,length) method returns only a subset of
> the given byte array, when it truly returns the entire array, only with a
> different position.
> So when the generated thrift file calls "readBinary()" in the generated
> "read()" function, it assumes only the appropriate subset is returned, which
> is not the case.
> That leads to errors when serializing/deserializing list of bytes, where the
> entire list gets returned instead of each object, if the underlying transport
> is buffered.
> So when trying to serialize/deserialize objects containing lists or maps of
> bytes, using TSerializer and TDeserializer, this problem occurs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
