[
https://issues.apache.org/jira/browse/HBASE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725488#comment-13725488
]
Nick Dimiduk commented on HBASE-9091:
-------------------------------------
For your mutability concerns, I'm not sure what to tell you other than that
you're talking to a clojure developer :) It wasn't clear to me from the API
that the class is intended to be immutable. The presence of independent setXXX
methods for offset and length threw me off. I'm up for a discussion about the
API here. I agree in that ByteBuffer is confusing in many cases. How does the
documentation I added, describing the class's three responsibilities, inform
our choices? Is that the right way to think about this class?
Perhaps there's some Java trickery with which I'm less familiar that can make
this class more palatable? Would thread-local variables help here?
As for responsibility of consumers, that's a contract that must be maintained
by consumers of the class. The methods in OrderedBytes and DataType can be made
more explicit about their handling of the position marker. In many places, I'm
careful to document expectations about changes the position marker or the
backing array, but I can review for that. The existing prefix code assumed
position didn't exist, so it's safe from this addition, at least at present.
> Update ByteRange to maintain consumer's position
> ------------------------------------------------
>
> Key: HBASE-9091
> URL: https://issues.apache.org/jira/browse/HBASE-9091
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Fix For: 0.95.2
>
> Attachments: 0001-HBASE-9091-Extend-ByteRange.patch,
> 0001-HBASE-9091-Extend-ByteRange.patch
>
>
> ByteRange is a useful alternative to Java's ByteBuffer. Notably, it is
> mutable and an instance can be assigned over a byte[] after instantiation.
> This is valuable as a performance consideration when working with byte[]
> slices in a tight loop. Its current design is such that it is not possible to
> consume a portion of the range while performing activities like decoding an
> object without altering the definition of the range. It should provide a
> position that is independent from the range's offset and length to make
> partial reads easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
