History log of /external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
b0575e93e4c39dec69365b850088a1eb7f82c5b3 04-Jun-2016 Tamas Berghammer <tberghammer@google.com> Update from protobuf v2.6.1 to protobuf 3.0.0-beta-3

This change just copies the upstream code into the repository without
fixing the Android.mk or fixing the possible cmpile errors. All of those
will be fixed with foloowup CLs.

Bug: b/28974522
Change-Id: I79fb3966dbef85915965692fa6ab14dc611ed9ea
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
4e97726326424715eda6a85d95122ba7abe25b35 08-Dec-2015 Joe Covalesky <jgc@google.com> Basic code insertion points for javanano protocompiler plugins.

Change-Id: I519e3882682638890150601270b74c38e5e8cb0e
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
c1db4a24ebb7c5e8a2e3f53fd5f26b6fed13ce47 01-Sep-2015 Giorgi Kvirkvia <kvirkvia@google.com> Call super.storeUnknownField in Nano protobufs.

Effect is reduced dexcount.

Change-Id: I6aad0c71f9b702b195c6a5964a20e1918d731701
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
bae6b59812ac972c9792605d521d6ada069288b2 02-Apr-2015 Jeff Davidson <jpd@google.com> Generate a CREATOR for each Parcelable message.

This is less ideal from a dex count perspective because it requires a
new variable for each message, and because most apps have proguard
rules that will ensure that CREATOR classes are retained.

However, it is required to be able to use nano protos inside of AIDL
files, as the autogenerated AIDL code fails to compile otherwise. This
is a substantial benefit as it allows for backwards-compatible
parameters and return types in AIDL methods along the lines of
safeparcel.

Bug: 19084705
Change-Id: I66a2c0424b96cf8ff6b631b186cc4f9407dfc1f4
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
0e2b47592a5af00251b2478542374a0f428ae4ee 20-Mar-2015 Brian Duff <bduff@google.com> Inline unknownFieldData{Equals,HashCode} to generated code.

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
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
c7c25812eb19d080087b71e08bfe35aff9f21433 09-Jan-2015 Brian Duff <bduff@google.com> Merge "When no clear() is generated, still initialize fields."
bcf45045f229edab8c2589c1f561e7b7495a763b 01-Oct-2014 Brian Duff <bduff@google.com> Add clone() method support for nano.

Upstreamed from Another Place (cr/57247854).

Change-Id: I2aaf59544c0f5ae21a51891d8a5eeda1dc722c90
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
5537d6fe4af105eb769bacc530e8d5d9e0b027cb 09-Jan-2015 Brian Duff <bduff@google.com> When no clear() is generated, still initialize fields.

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
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
907e776a4015b6b55987f008429ba66babb920a1 01-Oct-2014 Brian Duff <bduff@google.com> Change reftypes_primitive_enums to reftypes_compat_mode.

Make the clear() method stripped in reftypes_compat_mode.

Change-Id: I0ec35537856f59a6ecf231bfd74df995c858e2b2
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
d0a645c06c723bb309b78af8598ac51d1567f773 17-Sep-2014 Jason Neufeld <jneufeld@google.com> Includes a MessageNano subclass's name's hashCode in hashCode calculations.

In the current implementation, a message with the same amount of null or
equal-valued fields as a different message type will have the same
hashCode. This adds more variety by including the hashCode of the
class's name in the hashCode calculations.

Change-Id: I284e3e6d198ad8037815948d1f65686465ffd623
Signed-off-by: Jason Neufeld <jneufeld@google.com>
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
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/compiler/javanano/javanano_message.cc
721ea491a8e3e9ea5a130965dc5761fc335c3e61 23-Apr-2014 Jeff Davidson <jpd@google.com> Support generation of Parcelable nano messages.

This CL adds the "parcelable_messages" option. When enabled, all
generated message classes will conform to the Android Parcelable
contract. This is achieved by introducing a new parent class for
generated classes which implements the required functionality.

Since the store_unknown_fields option also makes use of a superclass,
ExtendableMessageNano, we have two versions of the new Parcelable
superclass: one extending MessageNano, and one extending
ExtendableMessageNano. These classes are otherwise identical.

As these classes depend on Android framework jars, they are not
included in the host .jar build of the nanoproto library.

Finally, add a test suite for running tests of Android-specific
functionality, as this cannot be done on a desktop JVM.

Change-Id: Icc2a257f03317e947f7078dbb9857c3286857497
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
c82101204dcde798f870d95e91f5483c3e57eb29 20-Mar-2014 Dave Hawkey <dhawkey@google.com> Don't reset cachedSize to 0 in getSerializedSize

This avoids a race-condition when cachedSize is momentarily set to 0
for non-empty messages if multiple threads call getSerializedSize
(e.g. during serialization).

This is a retry of https://android-review.googlesource.com/#/c/88570/.
getSerializedSize() has been kept non-final so that messages generated
with a previous version of the compiler will not break.

Change-Id: I8d8154a10938cde579ae19c55eae55b1e70e0bda
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
2d849337400b64ee913ece4631d3b2dbc95f20d8 22-Mar-2014 Wink Saville <wink@google.com> Revert "Don't reset cachedSize to 0 in getSerializedSize"

This reverts commit c6e12c6702ca764486f952654ba1568f00efe813.
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
c6e12c6702ca764486f952654ba1568f00efe813 20-Mar-2014 Dave Hawkey <dhawkey@google.com> Don't reset cachedSize to 0 in getSerializedSize

This avoids a race-condition when cachedSize is momentarily set to 0
for non-empty messages if multiple threads call getSerializedSize
(e.g. during serialization).

Change-Id: I15a8ded92edbf41bf1c8d787960c5bbbc8a323c5
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
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/compiler/javanano/javanano_message.cc
5cc242074f189837b38e7768b57ccfb0bca258df 09-Oct-2013 Max Cai <maxtroy@google.com> Avoid class initializers to help ProGuard.

Class initializers prevent ProGuard from inlining any methods
because it thinks the class initializer may have side effects.
This is true for static methods, but instance methods can still
be inlined, because to have an instance you will have touched
the class and any class initializers would have run. But
ProGuard only starts inlining instance methods of classes with
class initializers from v4.11b6, and Android uses v4.4 now.

This change tries to avoid the class initializers as much as
possible, by delaying the initialization of the empty array and
some fields' saved defaults until when they're needed. However,
if the message hosts any extensions, they must be public static
final and therefore introducing the class initializer. In that
case we won't bother with lazy initialization.

Change-Id: I00d8296f6eb0023112b93ee135cdb28dbd52b0b8
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
fea3fd5cb6ff88b51da60b1f33004944d93a9fce 13-Nov-2013 Max Cai <maxtroy@google.com> Align with main: two ways of parsing repeated packable fields.

It is a requirement for parsing code to handle packed and unpacked
forms on the wire for repeated packable fields. This change aligns
the javanano's behavior with the java's.

Bonus: optimize array length calculation when parsing repeated
fixed-size-element-type fields.

Bonus 2: lose "xMemoizedSerializedSize" for repeated enum fields,
and make the serialized size calculation match that for repeated
int32 fields.

Change-Id: I8a06103d9290234adb46b0971b5ed155544fe86a
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
7e02f374901ff471db5140f415de157ac6243050 11-Nov-2013 Tom Chao <chaot@google.com> Minimize method count for nanoproto.

- Migrates getCachedSize to the MessageNano parent class to save one method per message.
- Create ExtendableMessageNano parent class for protos with extensions, this saves the
getExtension and setExtension methods on the relevant messages.
- getSerializedSize's default case (with no fields to serialize) also migrate to the
parent class, which saves methods on empty messages.
- Container classes become interfaces to save the constructor.

Change-Id: I81f1a1b6d6a660096835e9df3ea20456655aab4a
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
ccc48faf20dbf3b3cddcffe78d198876d543529b 16-Oct-2013 Brian Duff <bduff@google.com> Implement hashCode() and equals() behind a generator option.

The option is only called 'generate_equals' because:
- equals() is the main thing; hashCode() is there only to
complement equals();
- it's shorter;
- toString() should not be included in this option because
it's more for debugging and it's more likely to stop
ProGuard from working well.

Also shortened the "has bit" expression; was
((bitField & mask) == mask), now ((bitField & mask) != 0).
Both the Java code and the bytecode are slightly shorter.

Change-Id: Ic309a08a60883bf454eb6612679aa99611620e76
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
286271f75aa6ff1f3746379b77d6dc55415baa16 14-Oct-2013 Max Cai <maxtroy@google.com> Make generated code more aligned with Google Java style.

- Blank line after opening a message class (but not an enum interface).
- Let all code blocks insert blank lines before themselves. This applies to
'package' statement, all message classes, enum classes or constant groups,
extensions, bitfields, proto fields (one block per field; i.e. accessors
don't have blank lines among them), and basic MessageNano methods. In this
case we don't need to guess what the next block is and create blank lines
for it.
- Fixed some newline/indent errors.
- Only one SuppressWarnings("hiding") per file.

Change-Id: I865f52ad4fb6ea3b3a98b97ac9d78d19fc46c858
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
5ae438cf71487d5bc8cb5c0d0e637f976734d110 11-Oct-2013 Max Cai <maxtroy@google.com> Remove all field initializers and let ctor call clear().

The field initializers have basically caused the compiled <init> method
to inline the whole clear() method, which means if ProGuard is not used
or failed to inline or remove clear(), there are two big chunks of code
that do the same thing. So why not just call clear() from the ctor.

Change-Id: Ief71e2b03db2e059b3bfa98309649368089ffab0
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
e74fe623e115237968a3de1143d7cdb4df710858 20-Sep-2013 Max Cai <maxtroy@google.com> Accessor style for optional fields.

This CL implements the 'optional_field_style=accessors' option.
All optional fields will now be 1 Java field and 1 bit in a shared
bitfield behind get/set/has/clear accessor methods. The setter
performs null check for reference types (Strings and byte[]s).

Also decentralized the clear code generation.

Change-Id: I60ac78329e352e76c2f8139fba1f292383080ad3
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
624c448fbef20a1a2fad2289f622b468c25763d1 29-Jul-2013 Max Cai <maxtroy@google.com> Fix outer classname for javamicro/javanano.

- File class name is defined as the java_outer_classname option value
or the file name ToCamelCase; never the single message's ClassName.
- File-scope enums are translated to constants in the file class,
regardless of java_multiple_files.
- If java_multiple_files=true, and file's class name equals a message's
class name, no error. This is done by detecting that the outer class
is not needed and skipping the outer class codegen and clash checks.
Note: there is a disparity between java[lite] and the previous
java{micr|nan}o: when generating code for a single-message proto, the
outer class is omitted by java{micr|nan}o if the file does not have
java_outer_classname. This change makes java{micr|nan}o align with
java[lite] codegen and create the outer class, but will print some
info to warn of potential change of code.
- Also fixed the "is_own_file" detection and made all parseX() methods
static. Previously, all messages in a java_multiple_files=true file
are (incorrectly) considered to be in their own files, including
nested messages, causing them to become inner classes (instance-
bound) and forcing the parseX() methods to lose the static modifier.
- This change supersedes c/60164 and c/60086, which causes javanano to
put enum values into enum shell classes if java_multiple_files=true.
We now always use the parent class to host the enum values. A future
change will add a command line option to provide more flexibility.
- Elaborated in java/README.txt.

Change-Id: I684932f90e0a028ef37c662b221def5ffa202439
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
35d9fd84ff1d9ecdb91156b757cc9fdcc3f25249 01-Apr-2013 Ulas Kirazci <ulas@google.com> Add an option to inspect "has" state upon parse.

If has is set, also always serialize.

Change-Id: I2c8450f7ab9e837d722123dd1042991c0258ede3
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
8170787391efcb6cc6a8babc1cce35d5b1aff420 24-Jul-2013 Max Cai <maxtroy@google.com> Per-file java_multiple_files flag.

Imported source files may have different values for the 'java_multiple_files'
option to the main source file's. Whether the fully qualified Java name of an
entity should include the outer class name depends on the flag value in the
file defining the referenced entity, not the main file. This CL loads the
flag values from the main and all transitively imported files into the params,
and generates the fully qualified Java names accordingly.

If the generator option 'java_multiple_files' is set, its value overrides any
in-file values in all source/imported files. This is because this generator
option is typically used on either none or all source files.

Change-Id: Id6a4a42426d68961dc669487d38f35530deb7d8e
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
f4e01452f159ae6b53f5edd25fa647ca2919ae10 18-Jul-2013 Tom Chao <chaot@google.com> Update nano to serialize java keywords properly.

Change-Id: I7407d0fab609c336ecd73499e725aed0dd50f555
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
19641419a381509bddfc2d0b5d60a411b67b105b 29-Jun-2013 Brian Duff <bduff@google.com> Make it possible to use MessageNano.mergeFrom without casting.

You can now do:

MyMessage foo = MessageNano.mergeFrom(new MyMessage(), bytes);

without having to cast the message returned from mergeFrom.

Change-Id: Ibb2ad327f75855d45352ad304c7f054f20dd29c9
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc
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/compiler/javanano/javanano_message.cc
64d8d8f89050c5ada85341f967af391f4716a7cb 15-Mar-2013 Ulas Kirazci <ulas@google.com> Nano protobufs.

Like micro protobufs except:

- No setter/getter/hazzer functions.
- Has state is not available. Outputs all fields != their default.
- CodedInputStream can only take byte[] (not InputStream).
- Repeated fields are in arrays, not ArrayList or Vector.
- Unset messages/groups are null, not "defaultInstance()".
- Required fields are always serialized.

To use:

- Link libprotobuf-java-2.3.0-nano runtime.
- Use LOCAL_PROTOC_OPTIMIZE_TYPE := nano

Change-Id: I7429015b3c5f7f38b7be01eb2d4927f7a9999c80
/external/protobuf/src/google/protobuf/compiler/javanano/javanano_message.cc