[
https://issues.apache.org/jira/browse/THRIFT-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907737#action_12907737
]
Mathias Herberts commented on THRIFT-894:
-----------------------------------------
in TBaseHelper.byteBufferToByteArray we should check the target array's size
and either only copy as much data as will fit in it or not copy anything if
there is not enough room.
Also we should have a warning mentioning the semantics of byte[] getXXX methods
in case you play with the underlying ByteBuffer.
If you make wrapsFullArray false, then the returned byte[] is no longer tied to
the struct and modifying it won't modify the struct's content.
Maybe bufferForXXX should be generated only if a special flag is set, or maybe
not at all. Does anyone have a use case for it?
> Make default accessors for binary fields return byte[]; provide new accessors
> to get ByteBuffer version
> -------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-894
> URL: https://issues.apache.org/jira/browse/THRIFT-894
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.5
>
> Attachments: thrift-894-v2.patch, thrift-894.patch
>
>
> Folks have pointed out that it's not always best for users to interact with
> the ByteBuffers that are now backing binary fields in our structs. In truth,
> it seems like ByteBuffers are probably an expert means of access, with
> associated benefits and complexities.
> I think we should generate two different sets of accessors for binary fields:
> a default set, named like usual, that return and take byte[], and a second
> set, named something like "get_buffer_for_<field>" that returns the
> underlying ByteBuffer. The byte[] accessors can wrap around the ByteBuffer
> ones as necessary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
