[
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.
