Apache
/
hbase
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HBASE-11169 nit: fix incorrect javadoc in OrderedBytes about BlobVar and BlobCopy 

git-svn-id: https://svn.apache.org/repos/asf/hbase/trunk@1595389 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Jonathan Hsieh 2014-05-16 23:42:57 +00:00
parent a5f6c55edd
commit a5cbd502bb
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
View File

@ -98,7 +98,7 @@ import com.google.common.annotations.VisibleForTesting;
* "BlobVar" encodes the input byte[] in a manner similar to a variable length
* integer encoding. As with the other {@code OrderedBytes} encodings,
* the first encoded byte is used to indicate what kind of value follows. This
* header byte is 0x35 for BlobVar encoded values. As with the traditional
* header byte is 0x37 for BlobVar encoded values. As with the traditional
* varint encoding, the most significant bit of each subsequent encoded
* {@code byte} is used as a continuation marker. The 7 remaining bits
* contain the 7 most significant bits of the first unencoded byte. The next
@ -112,7 +112,7 @@ import com.google.common.annotations.VisibleForTesting;
* </p>
* <h4>BlobCopy</h4>
* <p>
* "BlobCopy" is a simple byte-for-byte copy of the input data. It uses 0x36
* "BlobCopy" is a simple byte-for-byte copy of the input data. It uses 0x38
* as the header byte, and is terminated by 0x00 in the DESCENDING case. This
* alternative encoding is faster and more space-efficient, but it cannot
* accept values containing a 0x00 byte in DESCENDING order.