thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathias Herberts (JIRA)" <j...@apache.org>
Subject [jira] Commented: (THRIFT-1035) Container types containing binary data are parameterized with ByteBuffer in the generated Java code
Date Mon, 10 Jan 2011 06:43:46 GMT

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

Mathias Herberts commented on THRIFT-1035:
------------------------------------------

I'd like to have feedback on the following:

What if we modify the Java generator so that containers of binary data (list,set,map) are
implemented as List, Set, Map parameterized with byte[], while retaining the ByteBuffer implementation
for binary fields not in containers?

This would still provide the ability to benefit from the ByteBuffer optimization by replacing
'binary' with a simple wrapper 'struct BinaryWrapper { 1: binary content }' in container types
which might benefit from the faster I/Os.

TProtocol would need to be  modified to have a writeBinary(byte[])
 

> Container types containing binary data are parameterized with ByteBuffer in the generated
Java code
> ---------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-1035
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1035
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Compiler, Java - Library
>    Affects Versions: 0.4, 0.5, 0.6, 0.7
>         Environment: All
>            Reporter: Mathias Herberts
>
> Since THRIFT-830, binary fields are internally handled using ByteBuffer.
> Release 0.4.0 was the first to expose the ByteBuffer to the outside world (replacing
previous methods returning/accepting byte[]).
> THRIFT-882 lead to the methods accepting/returning byte[] being available again, as it
was deemed more reasonable not to expose the ByteBuffer too much as their use could be cumbersome.
This lead to 0.5.0 being backward compatible with 0.3.0 on the binary fields front.
> During that time, nobody noticed that container types that contained binary data had
their generated Java code changed to collections parameterized with ByteBuffer instead of
byte[].
> list<binary> -> List<ByteBuffer>
> set<binary> -> Set<ByteBuffer>
> map<binary,...> -> Map<ByteBuffer,...>
> map<...,binary> -> Map<...,ByteBuffer>
> This introduces confusion in the API and still exposes ByteBuffer when discussion on
THRIFT-882 concluded this should be avoided.
> We need to provide a way to offer the original parameterization with byte[] as this will
simplify working with that type of collection and thus will increase the odds of Thrift's
adoption.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message