[
https://issues.apache.org/jira/browse/THRIFT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895825#action_12895825
]
Mathias Herberts commented on THRIFT-830:
-----------------------------------------
For whatever it's worth, I don't feel comfortable with this issue, replacing
byte[] with ByteBuffer will break tons of code, thus making andry quite a few
people who are already coping with thrift betaness. Not good for adoption.
And on a more personal point of view it will also break the GWT compatibility
patch I've crafted for Thrift as GWT does not have ByteBuffer in its JRE
emulation layer.
Therefore -1.
> 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.
