You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hbase.apache.org by jm...@apache.org on 2014/05/17 01:42:57 UTC
svn commit: r1595389 -
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
Author: jmhsieh
Date: Fri May 16 23:42:57 2014
New Revision: 1595389
URL: http://svn.apache.org/r1595389
Log:
HBASE-11169 nit: fix incorrect javadoc in OrderedBytes about BlobVar and BlobCopy
Modified:
hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
Modified: hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
URL: http://svn.apache.org/viewvc/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java?rev=1595389&r1=1595388&r2=1595389&view=diff
==============================================================================
--- hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java (original)
+++ hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java Fri May 16 23:42:57 2014
@@ -98,7 +98,7 @@ import com.google.common.annotations.Vis
* "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.Vis
* </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.