[
https://issues.apache.org/jira/browse/ACCUMULO-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326152#comment-14326152
]
Keith Turner edited comment on ACCUMULO-2817 at 2/18/15 4:34 PM:
-----------------------------------------------------------------
As for creating new issues, I wanted to see how the discussion here went before
doing that. Was thinking of adding new decode method to the current
implementations w/o changing the interface. Code like the following using the
concrete implementations could still be written, which seems useful. In the
future when we switch to Java8 we can modify the interface. What are the
pitfalls of this approach?
{code:java}
LongLexicoder longLex = new LongLexicoder();
long l = longLex.decode(data, 5, 13);
{code}
was (Author: kturner):
As for creating new issues, I wanted to see how the discussion here went before
doing that. Was thinking of adding new decode method to the current
implementations w/o changing the interface. Code like the following using the
concrete implementations could still be written, which seems useful. In the
future when we switch to Java8 we can modify the interface. What are the
pitfalls of this approach?
{{code:java}}
LongLexicoder longLex = new LongLexicoder();
long l = longLex.decode(data, 5, 13);
{{code}}
> Add offset and limit arguments to byte array Encoder.decode method
> ------------------------------------------------------------------
>
> Key: ACCUMULO-2817
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2817
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.7.0
> Reporter: Josh Elser
> Assignee: Matt Dailey
> Labels: newbie
> Fix For: 1.7.0
>
> Attachments: ACCUMULO-2817.patch
>
>
> Similar to ACCUMULO-2445, but presently the encoder only works on complete
> byte arrays. This forces an extra copy of the data when it is located in an
> array that contains other information (e.g. a composite key).
> It would be nice to be able to provide offset and length arguments to
> {{Encoder.decode}} so that users can avoid the additional arraycopy.
> Changing to a ByteBuffer instead of byte array argument would also be
> acceptable, but more churn on the API that, unless it's happening globally, I
> would rather avoid. It would also incur the penalty for that extra Object,
> which while minimal alone, could be significant if decoding every value in a
> table, for example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
