Special values for float and double make it inaccurate to test the equality with ==.
The main Java library uses the standard Object.equals() implementation for all fields,
which for floating point fields means Float.equals() or Double.equals(). They define
equality as bitwise equality, with all NaN representations normalized to the same bit
sequence (and therefore equal to each other). This test checks that the nano
implementation complies with Object.equals(), so NaN == NaN and +0.0 != -0.0.
Change-Id: I97bb4a3687223d8a212c70cd736436b9dd80c1d7
- 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
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
For nested message objects, don't generate accessor methods because they have
a default value that is not a valid value (null), so there is no reason to have
get/set/has/clear methods for them. Clients and protos (while serializing) can
check against the invalid value to see if it's been set.
Change-Id: Ic63400889581271b8cbcd9c45c84519d4921fd4b
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
- 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
Strip the null elements out before serializing the array.
This is helpful in the cases where the user wants to construct
an array of an inexact size for serialization. For example:
User constructs array of size 5 because they anticipate adding
more than 1 element before serialization. Only 3 get added, so
the array looks like [Obj, Obj, Obj, null, null]. This would
curently crash without this CL.
All repeated fields of ref-type elements can contain null
elements: repeated strings, repeated bytes, and repeated
messages/groups.
Change-Id: I117391c868c9a436536d70d6151780e9cc7e8227
Conflicts:
src/google/protobuf/compiler/javanano/javanano_message_field.cc
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
Also pre-inlines set() and has() in serialization code. This could
theoretically help ProGuard: the message class size is usually large,
and because of this only, it may refuse to inline an accessor into
the serialization code, and as a result keeps the accessor intact.
Chances are, after pre-inlining all accessor calls within the message
class, those accessors become unused or single-use, so there are more
reasons for ProGuard to inline and then remove them.
Change-Id: I57decbe0b2533c1be21439de0aad15f49c7024dd
- 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
The public doc states that repeated fields are simply concatenated
and doesn't impose a different semantics for packed fields. This
CL fixes this for packed fields and adds tests covering all cases.
Also fixed a bit of missed null-repeated-field treatments.
Change-Id: Ie35277bb1a9f0b8171dc9d07b6adf9b9d3308de2
There's no distinction between a repeated field being null and being
empty. In both cases, nothing is sent on the wire. Clients might for
whatever reason inadvertently set a repeated field to null, so
protect against that and treat it just as if the field was empty.
Change-Id: Ic3846f7f2189d6cfff6f8ef3ca217daecc3c8be7
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
Previously it looked like this:
public final class OuterClass {
[...]
public static final class InnerClass extends
com.google.protobuf.nano.MessageNano {
[...]
public void setId(java.lang.String value) {
if (value == null) {
throw new java.lang.NullPointerException();
}
id_ = value;
bitfield0_ |= 0x00000001;
[...]
}
[...]
}
Now it looks like this:
public final class OuterClass {
[...]
public static final class InnerClass extends
com.google.protobuf.nano.MessageNano {
[...]
public void setId(java.lang.String value) {
if (value == null) throw new java.lang.NullPointerException();
id_ = value;
bitfield0_ |= 0x00000001;
[...]
}
[...]
}
Change-Id: I2a9289b528f785c846210d558206d677aa13e9be
This option generates fields as reference types, and serializes
based on nullness.
Change-Id: Ic32e0eebff59d14016cc9a19e15a9bb08ae0bba5
Signed-off-by: Brian Duff <bduff@google.com>
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
This javanano_out command line option creates a container interface
at the normal place where the enum constants would reside, per enum
definition. The java_multiple_files flag would now affect the file-
scope enums with the shells. If the flag is true then file-scope
container interfaces are created in their own files.
Change-Id: Id52258fcff8d3dee9db8f3d8022147a811bf3565
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
enum_style = c | java: 'c' to put the enum member int constants
at the parent scope; 'java' to create uninstantiatable shell
classes at the parent scope and put the int constants inside.
optional_field_style = default | accessors: 'default' to create
one public mutable field per optional proto field; 'accessors'
to encapsulate the generated fields behind get, set, has and
clear accessors.
This CL only contains parsing code for these two parameters.
Change-Id: Iec0c3b0f30af8eb7db328e790664306bc90be089
- 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
Remove buggy memoization. Memoization also is too fragile for the api
because the repeated field is public.
Change-Id: I538b8426d274b22df2eeea5935023abbe7df49fe
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
Adds support for default values of NaN, infinity and negative
infinity for floats and doubles in both the nano and micro
java compiler.
Change-Id: Ibc43e5ebb073e51d9a8181f3aa23b72e10015dca
You can now do:
MyMessage foo = MessageNano.mergeFrom(new MyMessage(), bytes);
without having to cast the message returned from mergeFrom.
Change-Id: Ibb2ad327f75855d45352ad304c7f054f20dd29c9
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
When the java_multiple_files option is on, enums are placed in java
class files based on the name of the original enum type. This fixes
field references to such enum values to point to the correct class
name when setting the default.
Change-Id: I51a2e251c0d0ab1e45a182ba849d314232a74bac
It didn't appear until API 9 and is thus incompatible with Froyo.
Instead, allocate a new array and System.arraycopy inline.
Change-Id: I2e1cd07a4a762ef8edd5ec06ceaa1d38b302823d
Max Cai
Andrew Flynn
Tom Chao
Aurash Mahbod
Brian Duff
Nicholas Seckar
Jon Skeet
Sergey Geyn
csharptest
xiaofeng@google.com
Ulas Kirazci
Chris Smith
Ficus Kirkpatrick