public final Class InternalNano

Helper called by generated code to construct default values for bytes fields.

This is a lot like stringDefaultValue, but for bytes fields. In this case we only need the second of the two hacks -- allowing us to embed raw bytes as a string literal with ISO-8859-1 encoding.

Helper function to convert a string into UTF-8 while turning the UnsupportedEncodingException to a RuntimeException.

Checks repeated int field equality; null-value and 0-length fields are considered equal.

Checks repeated long field equality; null-value and 0-length fields are considered equal.

Checks repeated float field equality; null-value and 0-length fields are considered equal.

Checks repeated double field equality; null-value and 0-length fields are considered equal.

Checks repeated boolean field equality; null-value and 0-length fields are considered equal.

Checks repeated bytes field equality. Only non-null elements are tested. Returns true if the two fields have the same sequence of non-null elements. Null-value fields and fields of any length with only null elements are considered equal.

Checks repeated string/message field equality. Only non-null elements are tested. Returns true if the two fields have the same sequence of non-null elements. Null-value fields and fields of any length with only null elements are considered equal.

Checks whether two Map are equal. We don't use the default equals method of Map because it compares by identity not by content for byte arrays.

Computes the hash code of a repeated int field. Null-value and 0-length fields have the same hash code.

Computes the hash code of a repeated long field. Null-value and 0-length fields have the same hash code.

Computes the hash code of a repeated float field. Null-value and 0-length fields have the same hash code.

Computes the hash code of a repeated double field. Null-value and 0-length fields have the same hash code.

Computes the hash code of a repeated boolean field. Null-value and 0-length fields have the same hash code.

Computes the hash code of a repeated bytes field. Only the sequence of all non-null elements are used in the computation. Null-value fields and fields of any length with only null elements have the same hash code.

Computes the hash code of a repeated string/message field. Only the sequence of all non-null elements are used in the computation. Null-value fields and fields of any length with only null elements have the same hash code.

Merges the map entry into the map field. Note this is only supposed to be called by generated messages.

Parameters

input:CodedInputByteBufferNano

the input byte buffer

map:Map<K, V>

the map field; may be null, in which case a map will be instantiated using the MapFactories.MapFactory

keyType:int

key type, as defined in InternalNano.TYPE_*

valueType:int

value type, as defined in InternalNano.TYPE_*

value:V

an new instance of the value, if the value is a TYPE_MESSAGE; otherwise this parameter can be null and will be ignored.

keyTag:int

wire tag for the key

valueTag:int

wire tag for the value

Returns:Map<K, V>

the map field

Annotations

@SuppressWarnings:unchecked

Helper called by generated code to construct default values for string fields.

The protocol compiler does not actually contain a UTF-8 decoder -- it just pushes UTF-8-encoded text around without touching it. The one place where this presents a problem is when generating Java string literals. Unicode characters in the string literal would normally need to be encoded using a Unicode escape sequence, which would require decoding them. To get around this, protoc instead embeds the UTF-8 bytes into the generated code and leaves it to the runtime library to decode them.

It gets worse, though. If protoc just generated a byte array, like: new byte[] {0x12, 0x34, 0x56, 0x78} Java actually generates *code* which allocates an array and then fills in each value. This is much less efficient than just embedding the bytes directly into the bytecode. To get around this, we need another work-around. String literals are embedded directly, so protoc actually generates a string literal corresponding to the bytes. The easiest way to do this is to use the ISO-8859-1 character set, which corresponds to the first 256 characters of the Unicode range. Protoc can then use good old CEscape to generate the string.

So we have a string literal which represents a set of bytes which represents another string. This function -- stringDefaultValue -- converts from the generated string to the string we actually want. The generated code calls this automatically.