This class is declared to be final, but declares fields to be protected. Since the class is final, it can not be derived from, and the use of protected is confusing.
When a MessageNano containing a String is serialized into a buffer that
is too small to contain it, and the buffer's boundary happens to be
where the string field's length delimiting varint is serialized,
and the string's length and 3*length have the same length when
encoded as a varint, an IllegalArgumentException is thrown rather than
an OutOfSpaceException.
Github issue: https://github.com/google/protobuf/issues/292
Change-Id: If478d68cf15bfd0662252d008e42b2bf1ff1c75e
It turns out dex (apparently) was inlining these protected final
methods from ExtendableMessageNano into every message class. Removing
these methods from the base class and inlining their code reduces
the method count by 2 methods / message when the store_unknown_fields
option is on.
Change-Id: I0aa09f2016d39939c4c8b8219601793b8fab301f
When building, some instances expect createMessageTyped to have the signature
(int, Class, long), while others expect (int, Class, int). Simply having
the former signature meant that builds expecting the latter would fail.
This is a cherrypick of change b2a9d4321578139677c146ce37eba5e27e8f5c79
from master.
Change-Id: Ib02dbf66173510f4edea32c7b43e82c1a7a38aa2
https://android-review.googlesource.com/#/c/67890/ removed field
initialization from the ctor, making it just call clear() instead.
When I added the generate_clear option back (as part of the reftypes
compat mode) in https://android-review.googlesource.com/#/c/109530/,
I forgot to ensure that what clear() used to do was inlined in the
constructor.
This change fixes NPEs that are happening for users of
reftypes_compat_mode who rely on unset repeated fields being empty
arrays rather than null.
Change-Id: Idb58746c60f4a4054b7ebb5c3b0e76b16ff88184
Measuring the serialized size of nano protos is now a zero-alloc operation, and serializing a proto now allocates no memory (other than the output buffer) instead of O(total length of strings).
Change-Id: Id5e2ac3bdc4ac56c0bf13d725472da3a00c9baec
Signed-off-by: Charles Munger <clm@google.com>
Previously, extensions with field numbers greater than 268435455 would
result in a compile time error in generated code that looks something
like this:
Foo.java:3178: error: integer number too large: 3346754610
3346754610);
This is because we were trying to represent the tag number (an
unsigned int) using a java int constant, but java int constants are
signed, and can't exceed Integer.MAX_VALUE.
Fixed by declaring it as a long instead, and casting it down to an
int in the implementation. This is safe, because the tag value always
fits in 32 bis.
Change-Id: If2017bacb4e20af667eaeaf9b65ddc2c30a7709f
wujingchao
Msp
Otto Kekäläinen
Feng Xiao
Xiao Hang
Jeff Davidson
Andre Eisenbach
Charles Munger
Brian Duff
Shai Barack
Kweku Adams
Tamir Duberstein
Jisi Liu