[
https://issues.apache.org/jira/browse/THRIFT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895832#action_12895832
]
Bryan Duxbury commented on THRIFT-830:
--------------------------------------
I recognize that it will break a lot of code. Luckily, that breakage is pretty
trivial, though. Also, we're making this change at a version boundary, so we
can announce the change cautiously.
As far as the GWT stuff goes, would it make sense to spin that off into a
separate generator that inherits from the standard Java generator, and
therefore can make its own adjustments?
> 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.
