[jira] [Commented] (THRIFT-830) Switch binary field implementation from byte[] to ByteBuffer

["Alik Elzin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264267#comment-14264267 ] 

Alik Elzin commented on THRIFT-830:
-----------------------------------

Waking up the dead...
I'm new to Thrift and the ByteBuffer is confusing:
1. Intuition - It gives the feeling of streaming, as if the server/client can continue update the the buffer and the other side will see the change.
2. Simplicity - byte[] is easy to grasp, exists in lots of languages and can always be wrapped with ByeBuffer. ByteBuffer on the other hand is more complex to grasp and I think exists in fewer languages.
3. Intention - ByteBuffer provides a state and meant to buffer data, but that's not the intention in Thrift. The intention in Thrift is different: Just passing data from over the network.
4. Convenience - I agree that internally, for Thrift generated code and library, it's easier to work with ByteBuffer. But that's not a concern for the users of Thrift. I think it's much more convenient for me to work with byte[].

This feels like the good old equivalent discussion to RISC vs. CISC. No right answer. I would just love things to be simple.

I didn't see the points I raised in the conversation. Where was I 4 years ago? Sorry.

> Switch binary field implementation from byte[] to ByteBuffer
> ------------------------------------------------------------
>
>                 Key: THRIFT-830
>                 URL: https://issues.apache.org/jira/browse/THRIFT-830
>             Project: Thrift
>          Issue Type: Sub-task
>          Components: Java - Compiler, Java - Library
>            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 was sent by Atlassian JIRA
(v6.3.4#6332)