History log of /external/protobuf/src/google/protobuf/unittest_extension_nano.proto
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
11f883e185a2ea6fd6d0b19520e9f0f004e90e5c 15-Jul-2014 Max Cai <maxtroy@google.com> Fix access around unknownFieldData.

Instead of publishing its class I chose to encapsulate the troublesome
references in equals()/hashCode() in the generated code into superclass
methods in ExtendableMessageNano.

Changed a couple of java packages in the test suite to catch this issue
easier in the future.

Change-Id: I43f88411f63bb6f3ffc8d63361f2f77bebf6220a
/external/protobuf/src/google/protobuf/unittest_extension_nano.proto
382ddccb550e1c822ef26a0e65988998f7446624 20-Nov-2013 Max Cai <maxtroy@google.com> Extension overhaul.

- Get rid of TypeLiteral<T>. It was introduced to read the component
type of a List<T> at runtime. But we use arrays everywhere else,
and we can always read the component type of an array type at
runtime.
- Properly read/write "minor" types (e.g. sint32, sfixed32). The old
implementation could only read/write data as the "typical" types
(one per Java type), e.g. java.lang.Integer -> int32, java.lang.Long
-> int64. So if e.g. an extension specifies sfixed32 as the type, it
would be read/written in the totally incompatible int32 format.
- Properly serialize repeated packed fields. The old implementation
doesn't do packed serialization. As an added bonus, and to be more
aligned with the rest of protobuf nano / main, repeated packable
extensions can deserialize both packed and non-packed data.
- Split Extension class into a hierarchy so under typical usage a
large chunk of code dealing with primitive type extensions can be
removed by ProGuard.

Bug: https://code.google.com/p/android/issues/detail?id=62586
Change-Id: I0d692f35cc2a8ad3a5a1cb3ce001282b2356b041
/external/protobuf/src/google/protobuf/unittest_extension_nano.proto
37ac79028de3d1cd8c215ba54fdf31e4eeca4b2c 25-Sep-2013 Nicholas Seckar <seckar@google.com> Fix roundtrip failure with groups when unknown fields are enabled.

When parsing a group, the group's end tag should not be stored within the
message's unknownFieldData. Not only does this waste space, it is also output
the next time the group is serialized, resulting in two end tags for that group.
The resulting bytes are not always a valid protocol buffer and may fail to
parse.

This change ensures that group end tags do not result in an unknownFieldData
entry, and that messages with groups can be roundtripped without corruption.

Change-Id: I240f858a7217a7652b756598c34aacad5dcc3363

Conflicts:
java/src/test/java/com/google/protobuf/NanoTest.java
/external/protobuf/src/google/protobuf/unittest_extension_nano.proto
0e055f079f53b07de3705838a7b4742ce56839f8 19-Jun-2013 Brian Duff <bduff@google.com> Nano support for extensions and unknown fields.

You can use the processor option store_unknown_fields to switch
this support on:

aprotoc --javanano_out=store_unknown_fields=true:/tmp/out

A separate option for extensions isn't required. Support
for unknown fields must be turned on to allow storing and
retrieving extensions, because they are just stored as
unknown fields. If unknown fields are switched on, extension
related code will be generated when a proto message includes
an extension range, or an extension is encountered.

By default, store_unknown_fields is false. No additional
code is generated, and the generator will error out if protos
contain extension ranges or extensions.

Change-Id: I1e034c9e8f3305612953f72438189a7da6ed2167
/external/protobuf/src/google/protobuf/unittest_extension_nano.proto