[jira] Updated: (THRIFT-882) deep copy of binary fields does not copy ByteBuffer characteristics (arrayOffset, position)

["Bryan Duxbury (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Duxbury updated THRIFT-882:
---------------------------------

    Comment: was deleted

(was: 
Yes, but this level of confusion (by veteran programmers) may show that 
the ByteBuffer low-level IO class may not be an ideal general-purpose 
data field for user-level generated Java structs.  Getting data out of 
the ByteBuffer seems a bit confusing and error prone.

I.e. if it were totally up to me, I probably wouldn't expose this in the 
default generated Java code for structs produced from an IDL.  I'd 
either make it an advanced compiler option, or only use it deep in the 
hidden engine guts, masked behind getters and setters that return 
simpler idempotent data types.


)

> deep copy of binary fields does not copy ByteBuffer characteristics (arrayOffset, position)
> -------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-882
>                 URL: https://issues.apache.org/jira/browse/THRIFT-882
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Compiler
>    Affects Versions: 0.4
>            Reporter: Mathias Herberts
>            Assignee: Bryan Duxbury
>             Fix For: 0.5
>
>         Attachments: thrift-882.patch
>
>
> Generated objects have a constructor which does a deep copy of an existing instance.
> For binary fields, the deep copy is done like that:
> {code}
>     if (other.isSetBinary_field()) {
>       this.binary_field = ByteBuffer.wrap(new byte[other.binary_field.limit() - other.binary_field.arrayOffset()]);
>       System.arraycopy(other.binary_field.array(), other.binary_field.arrayOffset(), binary_field.array(), 0, other.binary_field.limit() - other.binary_field.arrayOffset());
>     }
> {code}
> This copies the backing array of the ByteBuffer but does not set the position correctly.
> In various protocol implementations, ByteBuffer instances are serialized by considering data between position and limit, this means that an object created from another object might lead to different serialized data (and thus a different deserialized value) in case a ByteBuffer has a non default position (which can happen since ByteBuffers can be set).

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