accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2817) Add offset and limit arguments to byte array Encoder.decode method
Date Thu, 19 Feb 2015 16:00:14 GMT


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:
>             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

View raw message