Protocol Buffers - Google's data interchange format (grpc依赖)
https://developers.google.com/protocol-buffers/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
401 lines
16 KiB
401 lines
16 KiB
Protocol Buffers - Google's data interchange format |
|
=================================================== |
|
|
|
[![Build Status](https://travis-ci.org/google/protobuf.svg?branch=master)](https://travis-ci.org/google/protobuf) |
|
|
|
Copyright 2008 Google Inc. |
|
|
|
This directory contains the Java Protocol Buffers Nano runtime library. |
|
|
|
**Nano is no longer supported by protobuf team. We recommend Android users to |
|
use protobuf lite runtime instead.** |
|
|
|
Installation - With Maven |
|
------------------------- |
|
|
|
The Protocol Buffers build is managed using Maven. If you would |
|
rather build without Maven, see below. |
|
|
|
1) Install Apache Maven if you don't have it: |
|
|
|
http://maven.apache.org/ |
|
|
|
2) Build the C++ code, or obtain a binary distribution of protoc. If |
|
you install a binary distribution, make sure that it is the same |
|
version as this package. If in doubt, run: |
|
|
|
$ protoc --version |
|
|
|
You will need to place the protoc executable in ../src. (If you |
|
built it yourself, it should already be there.) |
|
|
|
3) Run the tests: |
|
|
|
$ mvn test |
|
|
|
If some tests fail, this library may not work correctly on your |
|
system. Continue at your own risk. |
|
|
|
4) Install the library into your Maven repository: |
|
|
|
$ mvn install |
|
|
|
5) If you do not use Maven to manage your own build, you can build a |
|
.jar file to use: |
|
|
|
$ mvn package |
|
|
|
The .jar will be placed in the "target" directory. |
|
|
|
Installation - Without Maven |
|
---------------------------- |
|
|
|
If you would rather not install Maven to build the library, you may |
|
follow these instructions instead. Note that these instructions skip |
|
running unit tests. |
|
|
|
1) Build the C++ code, or obtain a binary distribution of protoc. If |
|
you install a binary distribution, make sure that it is the same |
|
version as this package. If in doubt, run: |
|
|
|
$ protoc --version |
|
|
|
If you built the C++ code without installing, the compiler binary |
|
should be located in ../src. |
|
|
|
2) Invoke protoc to build DescriptorProtos.java: |
|
|
|
$ protoc --java_out=src/main/java -I../src \ |
|
../src/google/protobuf/descriptor.proto |
|
|
|
3) Compile the code in src/main/java using whatever means you prefer. |
|
|
|
4) Install the classes wherever you prefer. |
|
|
|
Nano version |
|
------------ |
|
|
|
JavaNano is a special code generator and runtime library designed specially for |
|
resource-restricted systems, like Android. It is very resource-friendly in both |
|
the amount of code and the runtime overhead. Here is an overview of JavaNano |
|
features compared with the official Java protobuf: |
|
|
|
- No descriptors or message builders. |
|
- All messages are mutable; fields are public Java fields. |
|
- For optional fields only, encapsulation behind setter/getter/hazzer/ |
|
clearer functions is opt-in, which provide proper 'has' state support. |
|
- For proto2, if not opted in, has state (field presence) is not available. |
|
Serialization outputs all fields not equal to their defaults |
|
(see important implications below). |
|
The behavior is consistent with proto3 semantics. |
|
- Required fields (proto2 only) are always serialized. |
|
- Enum constants are integers; protection against invalid values only |
|
when parsing from the wire. |
|
- Enum constants can be generated into container interfaces bearing |
|
the enum's name (so the referencing code is in Java style). |
|
- CodedInputByteBufferNano can only take byte[] (not InputStream). |
|
- Similarly CodedOutputByteBufferNano can only write to byte[]. |
|
- Repeated fields are in arrays, not ArrayList or Vector. Null array |
|
elements are allowed and silently ignored. |
|
- Full support for serializing/deserializing repeated packed fields. |
|
- Support extensions (in proto2). |
|
- Unset messages/groups are null, not an immutable empty default |
|
instance. |
|
- toByteArray(...) and mergeFrom(...) are now static functions of |
|
MessageNano. |
|
- The 'bytes' type translates to the Java type byte[]. |
|
|
|
The generated messages are not thread-safe for writes, but may be |
|
used simultaneously from multiple threads in a read-only manner. |
|
In other words, an appropriate synchronization mechanism (such as |
|
a ReadWriteLock) must be used to ensure that a message, its |
|
ancestors, and descendants are not accessed by any other threads |
|
while the message is being modified. Field reads, getter methods |
|
(but not getExtension(...)), toByteArray(...), writeTo(...), |
|
getCachedSize(), and getSerializedSize() are all considered read-only |
|
operations. |
|
|
|
IMPORTANT: If you have fields with defaults and opt out of accessors |
|
|
|
How fields with defaults are serialized has changed. Because we don't |
|
keep "has" state, any field equal to its default is assumed to be not |
|
set and therefore is not serialized. Consider the situation where we |
|
change the default value of a field. Senders compiled against an older |
|
version of the proto continue to match against the old default, and |
|
don't send values to the receiver even though the receiver assumes the |
|
new default value. Therefore, think carefully about the implications |
|
of changing the default value. Alternatively, turn on accessors and |
|
enjoy the benefit of the explicit has() checks. |
|
|
|
IMPORTANT: If you have "bytes" fields with non-empty defaults |
|
|
|
Because the byte buffer is now of mutable type byte[], the default |
|
static final cannot be exposed through a public field. Each time a |
|
message's constructor or clear() function is called, the default value |
|
(kept in a private byte[]) is cloned. This causes a small memory |
|
penalty. This is not a problem if the field has no default or is an |
|
empty default. |
|
|
|
Nano Generator options |
|
---------------------- |
|
|
|
``` |
|
java_package -> <file-name>|<package-name> |
|
java_outer_classname -> <file-name>|<package-name> |
|
java_multiple_files -> true or false |
|
java_nano_generate_has -> true or false [DEPRECATED] |
|
optional_field_style -> default or accessors |
|
enum_style -> c or java |
|
ignore_services -> true or false |
|
parcelable_messages -> true or false |
|
generate_intdefs -> true or false |
|
``` |
|
|
|
**java_package=\<file-name\>|\<package-name\>** (no default) |
|
|
|
This allows overriding the 'java_package' option value |
|
for the given file from the command line. Use multiple |
|
java_package options to override the option for multiple |
|
files. The final Java package for each file is the value |
|
of this command line option if present, or the value of |
|
the same option defined in the file if present, or the |
|
proto package if present, or the default Java package. |
|
|
|
**java_outer_classname=\<file-name\>|\<outer-classname\>** (no default) |
|
|
|
This allows overriding the 'java_outer_classname' option |
|
for the given file from the command line. Use multiple |
|
java_outer_classname options to override the option for |
|
multiple files. The final Java outer class name for each |
|
file is the value of this command line option if present, |
|
or the value of the same option defined in the file if |
|
present, or the file name converted to CamelCase. This |
|
outer class will nest all classes and integer constants |
|
generated from file-scope messages and enums. |
|
|
|
**java_multiple_files={true,false}** (no default) |
|
|
|
This allows overriding the 'java_multiple_files' option |
|
in all source files and their imported files from the |
|
command line. The final value of this option for each |
|
file is the value defined in this command line option, or |
|
the value of the same option defined in the file if |
|
present, or false. This specifies whether to generate |
|
package-level classes for the file-scope messages in the |
|
same Java package as the outer class (instead of nested |
|
classes in the outer class). File-scope enum constants |
|
are still generated as integer constants in the outer |
|
class. This affects the fully qualified references in the |
|
Java code. NOTE: because the command line option |
|
overrides the value for all files and their imported |
|
files, using this option inconsistently may result in |
|
incorrect references to the imported messages and enum |
|
constants. |
|
|
|
**java_nano_generate_has={true,false}** (default: false) |
|
|
|
DEPRECATED. Use optional_field_style=accessors. |
|
|
|
If true, generates a public boolean variable has\<fieldname\> |
|
accompanying each optional or required field (not present for |
|
repeated fields, groups or messages). It is set to false initially |
|
and upon clear(). If parseFrom(...) reads the field from the wire, |
|
it is set to true. This is a way for clients to inspect the "has" |
|
value upon parse. If it is set to true, writeTo(...) will ALWAYS |
|
output that field (even if field value is equal to its |
|
default). |
|
|
|
IMPORTANT: This option costs an extra 4 bytes per primitive field in |
|
the message. Think carefully about whether you really need this. In |
|
many cases reading the default works and determining whether the |
|
field was received over the wire is irrelevant. |
|
|
|
**optional_field_style={default,accessors,reftypes}** (default: default) |
|
|
|
Defines the style of the generated code for fields. |
|
|
|
* default |
|
|
|
In the default style, optional fields translate into public mutable |
|
Java fields, and the serialization process is as discussed in the |
|
"IMPORTANT" section above. |
|
|
|
* accessors |
|
|
|
When set to 'accessors', each optional field is encapsulated behind |
|
4 accessors, namely get\<fieldname\>(), set\<fieldname\>(), has\<fieldname\>() |
|
and clear\<fieldname\>() methods, with the standard semantics. The hazzer's |
|
return value determines whether a field is serialized, so this style is |
|
useful when you need to serialize a field with the default value, or check |
|
if a field has been explicitly set to its default value from the wire. |
|
|
|
In the 'accessors' style, required and nested message fields are still |
|
translated to one public mutable Java field each, repeated fields are still |
|
translated to arrays. No accessors are generated for them. |
|
|
|
IMPORTANT: When using the 'accessors' style, ProGuard should always |
|
be enabled with optimization (don't use -dontoptimize) and allowing |
|
access modification (use -allowaccessmodification). This removes the |
|
unused accessors and maybe inline the rest at the call sites, |
|
reducing the final code size. |
|
TODO(maxtroy): find ProGuard config that would work the best. |
|
|
|
* reftypes |
|
|
|
When set to 'reftypes', each proto field is generated as a public Java |
|
field. For primitive types, these fields use the Java reference types |
|
such as java.lang.Integer instead of primitive types such as int. |
|
|
|
In the 'reftypes' style, fields are initialized to null (or empty |
|
arrays for repeated fields), and their default values are not available. |
|
They are serialized over the wire based on equality to null. |
|
|
|
The 'reftypes' mode has some additional cost due to autoboxing and usage |
|
of reference types. In practice, many boxed types are cached, and so don't |
|
result in object creation. However, references do take slightly more memory |
|
than primitives. |
|
|
|
The 'reftypes' mode is useful when you want to be able to serialize fields |
|
with default values, or check if a field has been explicitly set to the |
|
default over the wire without paying the extra method cost of the |
|
'accessors' mode. |
|
|
|
Note that if you attempt to write null to a required field in the reftypes |
|
mode, serialization of the proto will cause a NullPointerException. This is |
|
an intentional indicator that you must set required fields. |
|
|
|
NOTE |
|
optional_field_style=accessors or reftypes cannot be used together with |
|
java_nano_generate_has=true. If you need the 'has' flag for any |
|
required field (you have no reason to), you can only use |
|
java_nano_generate_has=true. |
|
|
|
**enum_style={c,java}** (default: c) |
|
|
|
Defines where to put the int constants generated from enum members. |
|
|
|
* c |
|
|
|
Use C-style, so the enum constants are available at the scope where |
|
the enum is defined. A file-scope enum's members are referenced like |
|
'FileOuterClass.ENUM_VALUE'; a message-scope enum's members are |
|
referenced as 'Message.ENUM_VALUE'. The enum name is unavailable. |
|
This complies with the Micro code generator's behavior. |
|
|
|
* java |
|
|
|
Use Java-style, so the enum constants are available under the enum |
|
name and referenced like 'EnumName.ENUM_VALUE' (they are still int |
|
constants). The enum name becomes the name of a public interface, at |
|
the scope where the enum is defined. If the enum is file-scope and |
|
the java_multiple_files option is on, the interface will be defined |
|
in its own file. To reduce code size, this interface should not be |
|
implemented and ProGuard shrinking should be used, so after the Java |
|
compiler inlines all referenced enum constants into the call sites, |
|
the interface remains unused and can be removed by ProGuard. |
|
|
|
**ignore_services={true,false}** (default: false) |
|
|
|
Skips services definitions. |
|
|
|
Nano doesn't support services. By default, if a service is defined |
|
it will generate a compilation error. If this flag is set to true, |
|
services will be silently ignored, instead. |
|
|
|
**parcelable_messages={true,false}** (default: false) |
|
|
|
Android-specific option to generate Parcelable messages. |
|
|
|
**generate_intdefs={true,false}** (default: false) |
|
Android-specific option to generate @IntDef annotations for enums. |
|
|
|
If turned on, an '@IntDef' annotation (a public @interface) will be |
|
generated for each enum, and every integer parameter and return |
|
value in the generated code meant for this enum will be annotated |
|
with it. This interface is generated with the same name and at the |
|
same place as the enum members' container interfaces described |
|
above under 'enum_style=java', regardless of the enum_style option |
|
used. When this is combined with enum_style=java, the interface |
|
will be both the '@IntDef' annotation and the container of the enum |
|
members; otherwise the interface has an empty body. |
|
|
|
Your app must declare a compile-time dependency on the |
|
android-support-annotations library. |
|
|
|
For more information on how these @IntDef annotations help with |
|
compile-time type safety, see: |
|
https://sites.google.com/a/android.com/tools/tech-docs/support-annotations |
|
and |
|
https://developer.android.com/reference/android/support/annotation/IntDef.html |
|
|
|
|
|
To use nano protobufs within the Android repo: |
|
---------------------------------------------- |
|
|
|
- Set 'LOCAL_PROTOC_OPTIMIZE_TYPE := nano' in your local .mk file. |
|
When building a Java library or an app (package) target, the build |
|
system will add the Java nano runtime library to the |
|
LOCAL_STATIC_JAVA_LIBRARIES variable, so you don't need to. |
|
- Set 'LOCAL_PROTO_JAVA_OUTPUT_PARAMS := ...' in your local .mk file |
|
for any command-line options you need. Use commas to join multiple |
|
options. In the nano flavor only, whitespace surrounding the option |
|
names and values are ignored, so you can use backslash-newline or |
|
'+=' to structure your make files nicely. |
|
- The options will be applied to *all* proto files in LOCAL_SRC_FILES |
|
when you build a Java library or package. In case different options |
|
are needed for different proto files, build separate Java libraries |
|
and reference them in your main target. Note: you should make sure |
|
that, for each separate target, all proto files imported from any |
|
proto file in LOCAL_SRC_FILES are included in LOCAL_SRC_FILES. This |
|
is because the generator has to assume that the imported files are |
|
built using the same options, and will generate code that reference |
|
the fields and enums from the imported files using the same code |
|
style. |
|
- Hint: 'include $(CLEAR_VARS)' resets all LOCAL_ variables, including |
|
the two above. |
|
|
|
To use nano protobufs outside of Android repo: |
|
---------------------------------------------- |
|
|
|
- Link with the generated jar file |
|
\<protobuf-root\>java/target/protobuf-java-2.3.0-nano.jar. |
|
- Invoke with --javanano_out, e.g.: |
|
``` |
|
./protoc '--javanano_out=\ |
|
java_package=src/proto/simple-data.proto|my_package,\ |
|
java_outer_classname=src/proto/simple-data.proto|OuterName\ |
|
:.' src/proto/simple-data.proto |
|
``` |
|
|
|
Contributing to nano: |
|
--------------------- |
|
|
|
Please add/edit tests in NanoTest.java. |
|
|
|
Please run the following steps to test: |
|
|
|
- cd external/protobuf |
|
- ./configure |
|
- Run "make -j12 check" and verify all tests pass. |
|
- cd java |
|
- Run "mvn test" and verify all tests pass. |
|
- cd ../../.. |
|
- . build/envsetup.sh |
|
- lunch 1 |
|
- "make -j12 aprotoc libprotobuf-java-2.3.0-nano aprotoc-test-nano-params NanoAndroidTest" and |
|
check for build errors. |
|
- Plug in an Android device or start an emulator. |
|
- adb install -r out/target/product/generic/data/app/NanoAndroidTest.apk |
|
- Run: |
|
"adb shell am instrument -w com.google.protobuf.nano.test/android.test.InstrumentationTestRunner" |
|
and verify all tests pass. |
|
- repo sync -c -j256 |
|
- "make -j12" and check for build errors |
|
|
|
Usage |
|
----- |
|
|
|
The complete documentation for Protocol Buffers is available via the |
|
web at: |
|
|
|
https://developers.google.com/protocol-buffers/
|
|
|