[
https://issues.apache.org/jira/browse/ACCUMULO-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327669#comment-14327669
]
Keith Turner commented on ACCUMULO-2817:
----------------------------------------
Re {{public T decodeUnchecked(byte[] b, int offset, int len)}}, I thinking
avoiding the rechecking of arguments is good. I would make
{{decodeUnchecked}} private.
Re AbstractEncoder, I would have to see what you are thinking in a patch. Some
thoughts :
* If the abstract class no longer makes sense when we eventually have the
interface changes, then we may want to avoid it.
* If the abstract class contains mostly internal implementation code that is
not relevant to users, then put it in an impl package. If the code would be
relevant to users implementing their own lexicoders then put it in API package.
For example java has nice abstract classes like AbstractList that are useful
for anyone implementing a List.
> 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
> 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)
