aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/google/protobuf/compiler/javanano/javanano_message_field.cc
Commit message (Collapse)AuthorAge
* Remove javanano.Gravatar Feng Xiao2018-03-26
|
* Add std:: namespace prefix to set and map (#3332)Gravatar tanderson-google2017-07-09
| | | * Remove using std::{set,map}
* Add clone() method support for nano.Gravatar Brian Duff2015-04-28
| | | | | | Upstreamed from Another Place (cr/57247854). Change-Id: I2aaf59544c0f5ae21a51891d8a5eeda1dc722c90
* fix equal and hash for bytes field for javanano oneofGravatar Jisi Liu2015-02-19
|
* hashcode and equals for oneofs in nano.Gravatar Jisi Liu2015-02-19
|
* Equals for message oneof field in nano.Gravatar Jisi Liu2015-02-19
|
* Oneof message level elements (consts, case getter/clear) and messsage type ↵Gravatar Jisi Liu2015-02-19
| | | | field oneof support.
* Initial check-in for message oneof.Gravatar Jisi Liu2015-02-19
|
* Avoid class initializers to help ProGuard.Gravatar Max Cai2013-12-10
| | | | | | | | | | | | | | | | | | | 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
* Nano: don't generate accessor methods for nested methodsGravatar Andrew Flynn2013-12-09
| | | | | | | | | 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
* Allow for ref-type arrays containing null elements.Gravatar Aurash Mahbod2013-11-05
| | | | | | | | | | | | | | | | | | | 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
* Implement hashCode() and equals() behind a generator option.Gravatar Brian Duff2013-10-25
| | | | | | | | | | | | | | | | 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
* Feature request: set() and clear() accessors return thisGravatar Max Cai2013-10-16
| | | | | | | | | | | | 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
* Make generated code more aligned with Google Java style.Gravatar Max Cai2013-10-16
| | | | | | | | | | | | | | - 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
* Fix repeated field merging semantics.Gravatar Max Cai2013-10-15
| | | | | | | | | | 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
* Protect against null repeated fields.Gravatar Brian Duff2013-10-14
| | | | | | | | | 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
* Remove all field initializers and let ctor call clear().Gravatar Max Cai2013-10-11
| | | | | | | | | 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
* Accessor style for optional fields.Gravatar Max Cai2013-09-23
| | | | | | | | | | | 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
* Update nano to serialize java keywords properly.Gravatar Tom Chao2013-07-19
| | | | Change-Id: I7407d0fab609c336ecd73499e725aed0dd50f555
* Don't use Arrays.copyOf in generated code.Gravatar Ficus Kirkpatrick2013-04-08
| | | | | | | 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
* Prevent conflicts between local and proto variable names.Gravatar Ulas Kirazci2013-04-03
| | | | | | | Prefix access to proto variable names with "this.". Also remove unused GenerateMergingCode. Change-Id: I5f07d3252fc385c4174d9165b64785b40f676e17
* Nano protobufs.Gravatar Ulas Kirazci2013-04-01
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