[
https://issues.apache.org/jira/browse/THRIFT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895837#action_12895837
]
Mathias Herberts commented on THRIFT-830:
-----------------------------------------
The way my GWT extension is done is by generating special stripped down POJOs
intended to be used on the GWT client side and extra methods in regular Java
generated classes to convert to/from those stripped down POJOs.
Additionaly all the GWT service interfaces (both async and sync) are also
generated thus speeding up development.
Thus my GWT extension is intended more as a bridge than a standalone version of
generated code.
I'll make it evolve so the GWT POJOs still use byte[] and the conversion layer
correctly converts to/from ByteBuffer to byte[].
I retract my -1, if it improves the 'vanilla' java code, I'll adapt.
My -1 was just me being lazy...
> 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.
