[
https://issues.apache.org/jira/browse/THRIFT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895813#action_12895813
]
Nate McCall commented on THRIFT-830:
------------------------------------
I've only implemented this partially (simple inserts and gets), but it "worked"
for that. I'll be back on this next week and will let you know immediately if
anything comes up.
If you want to commit it, this would help us somewhat coordinating with
THRIFT-831 (could serve as a baseline for those patches until that is in), but
thats totally up to you.
> Switch binary field implementation from byte[] to ByteBuffer
> ------------------------------------------------------------
>
> Key: THRIFT-830
> URL: https://issues.apache.org/jira/browse/THRIFT-830
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java), Library (Java)
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Priority: Blocker
> Fix For: 0.4
>
> Attachments: thrift-830.patch
>
>
> Instead of using byte[] as the implementation for binary fields, let's use
> ByteBuffer.
> There's nothing that you can do with byte[] that you can't also do with
> ByteBuffer, and there are more things you can do with ByteBuffer. It opens
> the way for us to avoid needless buffer copies on serialization and
> deserialization. It gives us a generally accepted equals() and compareTo()
> implementation, so we don't have to have custom cases for that anymore.
> Making this change will probably cause more than a little bit of trauma,
> changing the method signatures in both TProtocol and generated code. It's
> _possible_ that I could be persuaded to support a command line switch for
> producing old-style byte[] methods in some contexts, but I'd love not to
> waste time supporting suboptimal features.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
