Releases: protocolbuffers/protobuf
Protocol Buffers v3.0.2
General
- Various bug fixes.
Objective C
- Fix for oneofs in proto3 syntax files where fields were set to the zero
value. - Fix for embedded null character in strings.
- CocoaDocs support
Ruby
- Fixed memory corruption bug in parsing that could occur under GC pressure.
Javascript
- jspb.Map is now properly exported to CommonJS modules.
C#
- Removed legacy_enum_values flag.
Protocol Buffers v3.0.0
Version 3.0.0
This change log summarizes all the changes since the last stable release
(v2.6.1). See the last section about changes since v3.0.0-beta-4.
Proto3
-
Introduced Protocol Buffers language version 3 (aka proto3).
When protocol buffers was initially open sourced it implemented Protocol
Buffers language version 2 (aka proto2), which is why the version number
started from v2.0.0. From v3.0.0, a new language version (proto3) is
introduced while the old version (proto2) will continue to be supported.The main intent of introducing proto3 is to clean up protobuf before pushing
the language as the foundation of Google's new API platform. In proto3, the
language is simplified, both for ease of use and to make it available in a
wider range of programming languages. At the same time a few features are
added to better support common idioms found in APIs.The following are the main new features in language version 3:
- Removal of field presence logic for primitive value fields, removal of
required fields, and removal of default values. This makes proto3
significantly easier to implement with open struct representations, as
in languages like Android Java, Objective C, or Go. - Removal of unknown fields.
- Removal of extensions, which are instead replaced by a new standard
type called Any. - Fix semantics for unknown enum values.
- Addition of maps (back-ported to proto2)
- Addition of a small set of standard types for representation of time,
dynamic data, etc (back-ported to proto2) - A well-defined encoding in JSON as an alternative to binary proto
encoding.
A new notion "syntax" is introduced to specify whether a .proto file
uses proto2 or proto3:// foo.proto syntax = "proto3"; message Bar {...}
If omitted, the protocol buffer compiler generates a warning and "proto2" is
used as the default. This warning will be turned into an error in a future
release.We recommend that new Protocol Buffers users use proto3. However, we do not
generally recommend that existing users migrate from proto2 from proto3 due
to API incompatibility, and we will continue to support proto2 for a long
time.Other significant changes in proto3.
- Removal of field presence logic for primitive value fields, removal of
-
Explicit "optional" keyword are disallowed in proto3 syntax, as fields are
optional by default; required fields are no longer supported. -
Removed non-zero default values and field presence logic for non-message
fields. e.g. has_xxx() methods are removed; primitive fields set to default
values (0 for numeric fields, empty for string/bytes fields) will be skipped
during serialization. -
Group fields are no longer supported in proto3 syntax.
-
Changed repeated primitive fields to use packed serialization by default in
proto3 (implemented for C++, Java, Python in this release). The user can
still disable packed serialization by setting packed to false for now. -
Added well-known type protos (any.proto, empty.proto, timestamp.proto,
duration.proto, etc.). Users can import and use these protos just like
regular proto files. Additional runtime support are available for each
language. -
Proto3 JSON is supported in several languages (fully supported in C++, Java,
Python and C# partially supported in Ruby). The JSON spec is defined in the
proto3 language guide:https://developers.google.com/protocol-buffers/docs/proto3#json
We will publish a more detailed spec to define the exact behavior of
proto3-conformant JSON serializers and parsers. Until then, do not rely
on specific behaviors of the implementation if it’s not documented in
the above spec. -
Proto3 enforces strict UTF-8 checking. Parsing will fail if a string
field contains non UTF-8 data.
General
-
Introduced new language implementations (C#, JavaScript, Ruby, Objective-C)
to proto3. -
Added support for map fields (implemented in both proto2 and proto3).
Map fields can be declared using the following syntax:message Foo { map<string, string> values = 1; }
The data of a map field is stored in memory as an unordered map and
can be accessed through generated accessors. -
Added a "reserved" keyword in both proto2 and proto3 syntax. Users can use
this keyword to declare reserved field numbers and names to prevent them
from being reused by other fields in the same message.To reserve field numbers, add a reserved declaration in your message:
message TestMessage { reserved 2, 15, 9 to 11, 3; }
This reserves field numbers 2, 3, 9, 10, 11 and 15. If a user uses any of
these as field numbers, the protocol buffer compiler will report an error.Field names can also be reserved:
message TestMessage { reserved "foo", "bar"; }
-
Added a deterministic serialization API (currently available in C++). The
deterministic serialization guarantees that given a binary, equal messages
will be serialized to the same bytes. This allows applications like
MapReduce to group equal messages based on the serialized bytes. The
deterministic serialization is, however, NOT canonical across languages; it
is also unstable across different builds with schema changes due to unknown
fields. Users who need canonical serialization, e.g. persistent storage in
a canonical form, fingerprinting, etc, should define their own
canonicalization specification and implement the serializer using reflection
APIs rather than relying on this API. -
Added a new field option "json_name". By default proto field names are
converted to "lowerCamelCase" in proto3 JSON format. This option can be
used to override this behavior and specify a different JSON name for the
field. -
Added conformance tests to ensure implementations are following proto3 JSON
specification.
C++
-
Added arena allocation support (for both proto2 and proto3).
Profiling shows memory allocation and deallocation constitutes a significant
fraction of CPU-time spent in protobuf code and arena allocation is a
technique introduced to reduce this cost. With arena allocation, new
objects are allocated from a large piece of preallocated memory and
deallocation of these objects is almost free. Early adoption shows 20% to
50% improvement in some Google binaries.To enable arena support, add the following option to your .proto file:
option cc_enable_arenas = true;
The protocol buffer compiler will generate additional code to make the generated
message classes work with arenas. This does not change the existing API
of protobuf messages and does not affect wire format. Your existing code
should continue to work after adding this option. In the future we will
make this option enabled by default.To actually take advantage of arena allocation, you need to use the arena
APIs when creating messages. A quick example of using the arena API:{ google::protobuf::Arena arena; // Allocate a protobuf message in the arena. MyMessage* message = Arena::CreateMessage<MyMessage>(&arena); // All submessages will be allocated in the same arena. if (!message->ParseFromString(data)) { // Deal with malformed input data. } // Must not delete the message here. It will be deleted automatically // when the arena is destroyed. }
Currently arena allocation does not work with map fields. Enabling arenas in a .proto
file containing map fields will result in compile errors in the generated
code. This will be addressed in a future release. -
Added runtime support for the Any type. To use Any in your proto file, first
import the definition of Any:// foo.proto import "google/protobuf/any.proto"; message Foo { google.protobuf.Any any_field = 1; } message Bar { int32 value = 1; }
Then in C++ you can access the Any field using PackFrom()/UnpackTo()
methods:Foo foo; Bar bar = ...; foo.mutable_any_field()->PackFrom(bar); ... if (foo.any_field().IsType<Bar>()) { foo.any_field().UnpackTo(&bar); ... }
-
In text format, the entries of a map field will be sorted by key.
-
Introduced new utility functions/classes in the google/protobuf/util
directory:- MessageDifferencer: compare two proto messages and report their
differences. - JsonUtil: support converting protobuf binary format to/from JSON.
- TimeUtil: utility functions to work with well-known types Timestamp
and Duration. - FieldMaskUtil: utility functions to work with FieldMask.
- MessageDifferencer: compare two proto messages and report their
-
Introduced a deterministic serialization API in
CodedOutputStream::SetSerializationDeterministic(bool). See the notes about
deterministic serialization in the General section.
Java
- Introduced a new util package that will be distributed as a separate
artifact in maven. It contains:- JsonFormat: convert proto messages to/from JSON.
- Timestamps/Durations: utility functions to work with Timestamp and Duration.
- FieldMaskUtil: utility functions to work with FieldMask.
- Introduced an ExperimentalApi annotation. Annotated APIs are experimental
and are subject to change in a backward incompatible way in future releases. - Introduced zero-copy serialization as an ExperimentalApi
- Introduction of the
ByteOutput
interface. This is similar to
OutputStream
but provides semantics for lazy writing (i.e. no
immediate copy required) of fields that are considered to be immutable. ByteString
now supports writing to aByteOutput
, which will directly
expose the internals of theByteString
(i.e.byte[]
orByteBuffer
)
to theByteOutput
without copying.CodedOutputStream
now supports writing to aByteOutput
.ByteString
instances that are too large to fit in the internal buffer will be
(lazily) written to theByteOutput
directly.
...
- Introduction of the
Protocol Buffers v3.0.0-beta-4
Version 3.0.0-beta-4
General
-
Added a deterministic serialization API for C++. The deterministic
serialization guarantees that given a binary, equal messages will be
serialized to the same bytes. This allows applications like MapReduce to
group equal messages based on the serialized bytes. The deterministic
serialization is, however, NOT canonical across languages; it is also
unstable across different builds with schema changes due to unknown fields.
Users who need canonical serialization, e.g. persistent storage in a
canonical form, fingerprinting, etc, should define their own
canonicalization specification and implement the serializer using reflection
APIs rather than relying on this API. -
Added OneofOptions. You can now define custom options for oneof groups.
import "google/protobuf/descriptor.proto"; extend google.protobuf.OneofOptions { optional int32 my_oneof_extension = 12345; } message Foo { oneof oneof_group { (my_oneof_extension) = 54321; ... } }
C++ (beta)
- Introduced a deterministic serialization API in
CodedOutputStream::SetSerializationDeterministic(bool). See the notes about
deterministic serialization in the General section. - Added google::protobuf::Map::swap() to swap two map fields.
- Fixed a memory leak when calling Reflection::ReleaseMessage() on a message
allocated on arena. - Improved error reporting when parsing text format protos.
- JSON
- Added a new parser option to ignore unknown fields when parsing JSON.
- Added convenient methods for message to/from JSON conversion.
- Various performance optimizations.
Java (beta)
- File option "java_generate_equals_and_hash" is now deprecated. equals() and
hashCode() methods are generated by default. - Added a new JSON printer option "omittingInsignificantWhitespace" to produce
a more compact JSON output. The printer will pretty-print by default. - Updated Java runtime to be compatible with 2.5.0/2.6.1 generated protos.
Python (beta)
- Added support to pretty print Any messages in text format.
- Added a flag to ignore unknown fields when parsing JSON.
- Bugfix: "@type" field of a JSON Any message is now correctly put before
other fields.
Objective-C (beta)
- Updated the code to support compiling with more compiler warnings
enabled. (Issue 1616) - Exposing more detailed errors for parsing failures. (PR 1623)
- Small (breaking) change to the naming of some methods on the support classes
for map<>. There were collisions with the system provided KVO support, so
the names were changed to avoid those issues. (PR 1699) - Fixed for proper Swift bridging of error handling during parsing. (PR 1712)
- Complete support for generating sources that will go into a Framework and
depend on generated sources from other Frameworks. (Issue 1457)
C# (beta)
- RepeatedField optimizations.
- Support for .NET Core.
- Minor bug fixes.
- Ability to format a single value in JsonFormatter (advanced usage only).
- Modifications to attributes applied to generated code.
Javascript (alpha)
- Maps now have a real map API instead of being treated as repeated fields.
- Well-known types are now provided in the google-protobuf package, and the
code generator knows to require() them from that package. - Bugfix: non-canonical varints are correctly decoded.
Ruby (alpha)
- Accessors for oneof fields now return default values instead of nil.
Java Lite
- Java lite support is removed from protocol compiler. It will be supported
as a protocol compiler plugin in a separate code branch.
Protocol Buffers v3.0.0-beta-3.1
Fix iOS framework.
Protocol Buffers v3.0.0-beta-3
Version 3.0.0-beta-3
General
- Supported Proto3 lite-runtime in C++/Java for mobile platforms.
- Any type now supports APIs to specify prefixes other than
type.googleapis.com - Removed javanano_use_deprecated_package option; Nano will always has its own
".nano" package.
C++ (Beta)
- Improved hash maps.
- Improved hash maps comments. In particular, please note that equal hash
maps will not necessarily have the same iteration order and
serialization. - Added a new hash maps implementation that will become the default in a
later release.
- Improved hash maps comments. In particular, please note that equal hash
- Arenas
- Several inlined methods in Arena were moved to out-of-line to improve
build performance and code size. - Added SpaceAllocatedAndUsed() to report both space used and allocated
- Added convenient class UnsafeArenaAllocatedRepeatedPtrFieldBackInserter
- Several inlined methods in Arena were moved to out-of-line to improve
- Any
- Allow custom type URL prefixes in Any packing.
- TextFormat now expand the Any type rather than printing bytes.
- Performance optimizations and various bug fixes.
Java (Beta)
- Introduced an ExperimentalApi annotation. Annotated APIs are experimental
and are subject to change in a backward incompatible way in future releases. - Introduced zero-copy serialization as an ExperimentalApi
- Introduction of the
ByteOutput
interface. This is similar to
OutputStream
but provides semantics for lazy writing (i.e. no
immediate copy required) of fields that are considered to be immutable. ByteString
now supports writing to aByteOutput
, which will directly
expose the internals of theByteString
(i.e.byte[]
orByteBuffer
)
to theByteOutput
without copying.CodedOutputStream
now supports writing to aByteOutput
.ByteString
instances that are too large to fit in the internal buffer will be
(lazily) written to theByteOutput
directly.- This allows applications using large
ByteString
fields to avoid
duplication of these fields entirely. Such an application can supply a
ByteOutput
that chains together the chunks received from
CodedOutputStream
before forwarding them onto the IO system.
- Introduction of the
- Other related changes to
CodedOutputStream
- Additional use of
sun.misc.Unsafe
where possible to perform fast
access tobyte[]
andByteBuffer
values and avoiding unnecessary
range checking. ByteBuffer
-backedCodedOutputStream
now writes directly to the
ByteBuffer
rather than to an intermediate array.
- Additional use of
- Improved lite-runtime.
- Lite protos now implement deep equals/hashCode/toString
- Significantly improved the performance of Builder#mergeFrom() and
Builder#mergeDelimitedFrom()
- Various bug fixes and small feature enhancement.
- Fixed stack overflow when in hashCode() for infinite recursive oneofs.
- Fixed the lazy field parsing in lite to merge rather than overwrite.
- TextFormat now supports reporting line/column numbers on errors.
- Updated to add appropriate @OverRide for better compiler errors.
Python (Beta)
- Added JSON format for Any, Struct, Value and ListValue
- "[ ]" is now accepted for both repeated scalar fields and repeated message
fields in text format parser. - Numerical field name is now supported in text format.
- Added DiscardUnknownFields API for python protobuf message.
Objective-C (Beta)
- Proto comments now come over as HeaderDoc comments in the generated sources
so Xcode can pick them up and display them. - The library headers have been updated to use HeaderDoc comments so Xcode can
pick them up and display them. - The per message and per field overhead in both generated code and runtime
object sizes was reduced. - Generated code now include deprecated annotations when the proto file
included them.
C# (Beta)
In general: some changes are breaking, which require regenerating messages.
Most user-written code will not be impacted except for the renaming of enum
values.
- Allow custom type URL prefixes in
Any
packing, and ignore them when
unpacking protoc
is now in a separate NuGet package (Google.Protobuf.Tools)- New option:
internal_access
to generate internal classes - Enum values are now PascalCased, and if there's a prefix which matches the
name of the enum, that is removed (so an enumCOLOR
with a value
COLOR_BLUE
would generate a value of justBlue
). An option
(legacy_enum_values
) is temporarily available to disable this, but the
option will be removed for GA. json_name
option is now honored- If group tags are encountered when parsing, they are validated more
thoroughly (although we don't support actual groups) - NuGet dependencies are better specified
- Breaking:
Preconditions
is renamed toProtoPreconditions
- Breaking:
GeneratedCodeInfo
is renamed toGeneratedClrTypeInfo
JsonFormatter
now allows writing to aTextWriter
- New interface,
ICustomDiagnosticMessage
to allow more compact
representations fromToString
CodedInputStream
andCodedOutputStream
now implementIDisposable
,
which simply disposes of the streams they were constructed with- Map fields no longer support null values (in line with other languages)
- Improvements in JSON formatting and parsing
Javascript (Alpha)
- Better support for "bytes" fields: bytes fields can be read as either a
base64 string or UInt8Array (in environments where TypedArray is supported). - New support for CommonJS imports. This should make it easier to use the
JavaScript support in Node.js and tools like WebPack. See js/README.md for
more information. - Some significant internal refactoring to simplify and modularize the code.
Ruby (Alpha)
- JSON serialization now properly uses camelCased names, with a runtime option
that will preserve original names from .proto files instead. - Well-known types are now included in the distribution.
- Release now includes binary gems for Windows, Mac, and Linux instead of just
source gems. - Bugfix for serializing oneofs.
C++/Java Lite (Alpha)
A new "lite" generator parameter was introduced in the protoc for C++ and
Java for Proto3 syntax messages. Example usage:
./protoc --cpp_out=lite:$OUTPUT_PATH foo.proto
The protoc will treat the current input and all the transitive dependencies
as LITE. The same generator parameter must be used to generate the
dependencies.
In Proto3 syntax files, "optimized_for=LITE_RUNTIME" is no longer supported.
Protocol Buffers v3.0.0-beta-2
Version 3.0.0-beta-2
General
- Introduced a new language implementation: JavaScript.
- Added a new field option "json_name". By default proto field names are
converted to "lowerCamelCase" in proto3 JSON format. This option can be
used to override this behavior and specify a different JSON name for the
field. - Added conformance tests to ensure implementations are following proto3 JSON
specification.
C++ (Beta)
- Various bug fixes and improvements to the JSON support utility:
- Duplicate map keys in JSON are now rejected (i.e., translation will
fail). - Fixed wire-format for google.protobuf.Value/ListValue.
- Fixed precision loss when converting google.protobuf.Timestamp.
- Fixed a bug when parsing invalid UTF-8 code points.
- Fixed a memory leak.
- Reduced call stack usage.
- Duplicate map keys in JSON are now rejected (i.e., translation will
Java (Beta)
- Cleaned up some unused methods on CodedOutputStream.
- Presized lists for packed fields during parsing in the lite runtime to
reduce allocations and improve performance. - Improved the performance of unknown fields in the lite runtime.
- Introduced UnsafeByteStrings to support zero-copy ByteString creation.
- Various bug fixes and improvements to the JSON support utility:
- Fixed a thread-safety bug.
- Added a new option “preservingProtoFieldNames” to JsonFormat.
- Added a new option “includingDefaultValueFields” to JsonFormat.
- Updated the JSON utility to comply with proto3 JSON specification.
Python (Beta)
- Added proto3 JSON format utility. It includes support for all field types
and a few well-known types except for Any and Struct. - Added runtime support for Any, Timestamp, Duration and FieldMask.
- "[ ]" is now accepted for repeated scalar fields in text format parser.
Objective-C (Beta)
- Various bug-fixes and code tweaks to pass more strict compiler warnings.
- Now has conformance test coverage and is passing all tests.
C# (Beta)
- Various bug-fixes.
- Code generation: Files generated in directories based on namespace.
- Code generation: Include comments from .proto files in XML doc
comments (naively) - Code generation: Change organization/naming of "reflection class" (access
to file descriptor) - Code generation and library: Add Parser property to MessageDescriptor,
and introduce a non-generic parser type. - Library: Added TypeRegistry to support JSON parsing/formatting of Any.
- Library: Added Any.Pack/Unpack support.
- Library: Implemented JSON parsing.
Javascript (Alpha)
- Added proto3 support for JavaScript. The runtime is written in pure
JavaScript and works in browsers and in Node.js. To generate JavaScript
code for your proto, invoke protoc with "--js_out". See js/README.md
for more build instructions.
Protocol Buffers v3.0.0-beta-1
Version 3.0.0-beta-1
Supported languages
- C++/Java/Python/Ruby/Nano/Objective-C/C#
About Beta
- This is the first beta release of protobuf v3.0.0. Not all languages
have reached beta stage. Languages not marked as beta are still in
alpha (i.e., be prepared for API breaking changes).
General
-
Proto3 JSON is supported in several languages (fully supported in C++
and Java, partially supported in Ruby/C#). The JSON spec is defined in
the proto3 language guide:https://developers.google.com/protocol-buffers/docs/proto3#json
We will publish a more detailed spec to define the exact behavior of
proto3-conformant JSON serializers and parsers. Until then, do not rely
on specific behaviors of the implementation if it’s not documented in
the above spec. More specifically, the behavior is not yet finalized for
the following:- Parsing invalid JSON input (e.g., input with trailing commas).
- Non-camelCase names in JSON input.
- The same field appears multiple times in JSON input.
- JSON arrays contain “null” values.
- The message has unknown fields.
-
Proto3 now enforces strict UTF-8 checking. Parsing will fail if a string
field contains non UTF-8 data.
C++ (Beta)
- Introduced new utility functions/classes in the google/protobuf/util
directory:- MessageDifferencer: compare two proto messages and report their
differences. - JsonUtil: support converting protobuf binary format to/from JSON.
- TimeUtil: utility functions to work with well-known types Timestamp
and Duration. - FieldMaskUtil: utility functions to work with FieldMask.
- MessageDifferencer: compare two proto messages and report their
- Performance optimization of arena construction and destruction.
- Bug fixes for arena and maps support.
- Changed to use cmake for Windows Visual Studio builds.
- Added Bazel support.
Java (Beta)
- Introduced a new util package that will be distributed as a separate
artifact in maven. It contains:- JsonFormat: convert proto messages to/from JSON.
- TimeUtil: utility functions to work with Timestamp and Duration.
- FieldMaskUtil: utility functions to work with FieldMask.
- The static PARSER in each generated message is deprecated, and it will
be removed in a future release. A static parser() getter is generated
for each message type instead. - Performance optimizations for String fields serialization.
- Performance optimizations for Lite runtime on Android:
- Reduced allocations
- Reduced method overhead after ProGuarding
- Reduced code size after ProGuarding
Python (Alpha)
- Removed legacy Python 2.5 support.
- Moved to a single Python 2.x/3.x-compatible codebase, instead of using 2to3.
- Fixed build/tests on Python 2.6, 2.7, 3.3, and 3.4.
- Pure-Python works on all four.
- Python/C++ implementation works on all but 3.4, due to changes in the
Python/C++ API in 3.4.
- Some preliminary work has been done to allow for multiple DescriptorPools
with Python/C++.
Ruby (Alpha)
- Many bugfixes:
- fixed parsing/serialization of bytes, sint, sfixed types
- other parser bugfixes
- fixed memory leak affecting Ruby 2.2
JavaNano (Alpha)
- JavaNano generated code now will be put in a nano package by default to
avoid conflicts with Java generated code.
Objective-C (Alpha)
- Added non-null markup to ObjC library. Requires SDK 8.4+ to build.
- Many bugfixes:
- Removed the class/enum filter.
- Renamed some internal types to avoid conflicts with the well-known types
protos. - Added missing support for parsing repeated primitive fields in packed or
unpacked forms. - Added *Count for repeated and map<> fields to avoid auto-create when
checking for them being set.
C# (Alpha)
- Namespace changed to Google.Protobuf (and NuGet package will be named
correspondingly). - Target platforms now .NET 4.5 and selected portable subsets only.
- Removed lite runtime.
- Reimplementation to use mutable message types.
- Null references used to represent "no value" for message type fields.
- Proto3 semantics supported; proto2 files are prohibited for C# codegen.
Most proto3 features supported:- JSON formatting (a.k.a. serialization to JSON), including well-known
types (except for Any). - Wrapper types mapped to nullable value types (or string/ByteString
allowing nullability). JSON parsing is not supported yet. - maps
- oneof
- enum unknown value preservation
- JSON formatting (a.k.a. serialization to JSON), including well-known
Protocol Buffers v3.0.0-alpha-3
Version 3.0.0-alpha-3 (C++/Java/Python/Ruby/JavaNano/Objective-C/C#)
General
-
Introduced two new language implementations (Objective-C, C#) to proto3.
-
Explicit "optional" keyword are disallowed in proto3 syntax, as fields are
optional by default. -
Group fields are no longer supported in proto3 syntax.
-
Changed repeated primitive fields to use packed serialization by default in
proto3 (implemented for C++, Java, Python in this release). The user can
still disable packed serialization by setting packed to false for now. -
Added well-known type protos (any.proto, empty.proto, timestamp.proto,
duration.proto, etc.). Users can import and use these protos just like
regular proto files. Addtional runtime support will be added for them in
future releases (in the form of utility helper functions, or having them
replaced by language specific types in generated code). -
Added a "reserved" keyword in both proto2 and proto3 syntax. User can use
this keyword to declare reserved field numbers and names to prevent them
from being reused by other fields in the same message.To reserve field numbers, add a reserved declaration in your message:
message TestMessage { reserved 2, 15, 9 to 11, 3; }
This reserves field numbers 2, 3, 9, 10, 11 and 15. If a user uses any of
these as field numbers, the protocol buffer compiler will report an error.Field names can also be reserved:
message TestMessage { reserved "foo", "bar"; }
-
Various bug fixes since 3.0.0-alpha-2
Objective-C
-
Objective-C includes a code generator and a native objective-c runtime
library. By adding “--objc_out” to protoc, the code generator will generate
a header(.pbobjc.h) and an implementation file(.pbobjc.m) for each proto
file.In this first release, the generated interface provides: enums, messages,
field support(single, repeated, map, oneof), proto2 and proto3 syntax
support, parsing and serialization. It’s compatible with ARC and non-ARC
usage. Besides, user can also access it via the swift bridging header.See objectivec/README.md for details.
C#
-
C# protobufs are based on project
https://github.com/jskeet/protobuf-csharp-port. The original project was
frozen and all the new development will happen here. -
Codegen plugin for C# was completely rewritten to C++ and is now an
intergral part of protoc. -
Some refactorings and cleanup has been applied to the C# runtime library.
-
Only proto2 is supported in C# at the moment, proto3 support is in
progress and will likely bring significant breaking changes to the API.See csharp/README.md for details.
C++
-
Added runtime support for Any type. To use Any in your proto file, first
import the definition of Any:// foo.proto import "google/protobuf/any.proto"; message Foo { google.protobuf.Any any_field = 1; } message Bar { int32 value = 1; }
Then in C++ you can access the Any field using PackFrom()/UnpackTo()
methods:Foo foo; Bar bar = ...; foo.mutable_any_field()->PackFrom(bar); ... if (foo.any_field().IsType<Bar>()) { foo.any_field().UnpackTo(&bar); ... }
-
In text format, entries of a map field will be sorted by key.
Java
- Continued optimizations on the lite runtime to improve performance for
Android.
Python
- Added map support.
- maps now have a dict-like interface (msg.map_field[key] = value)
- existing code that modifies maps via the repeated field interface
will need to be updated.
Ruby
- Improvements to RepeatedField's emulation of the Ruby Array API.
- Various speedups and internal cleanups.
Protocol Buffers v3.0.0-alpha-2
Version 3.0.0-alpha-2 (C++/Java/Python/Ruby/JavaNano)
General
-
Introduced Protocol Buffers language version 3 (aka proto3).
When protobuf was initially opensourced it implemented Protocol Buffers
language version 2 (aka proto2), which is why the version number
started from v2.0.0. From v3.0.0, a new language version (proto3) is
introduced while the old version (proto2) will continue to be supported.The main intent of introducing proto3 is to clean up protobuf before
pushing the language as the foundation of Google's new API platform.
In proto3, the language is simplified, both for ease of use and to
make it available in a wider range of programming languages. At the
same time a few features are added to better support common idioms
found in APIs.The following are the main new features in language version 3:
- Removal of field presence logic for primitive value fields, removal
of required fields, and removal of default values. This makes proto3
significantly easier to implement with open struct representations,
as in languages like Android Java, Objective C, or Go. - Removal of unknown fields.
- Removal of extensions, which are instead replaced by a new standard
type called Any. - Fix semantics for unknown enum values.
- Addition of maps.
- Addition of a small set of standard types for representation of time,
dynamic data, etc. - A well-defined encoding in JSON as an alternative to binary proto
encoding.
This release (v3.0.0-alpha-2) includes partial proto3 support for C++,
Java, Python, Ruby and JavaNano. Items 6 (well-known types) and 7
(JSON format) in the above feature list are not implemented.A new notion "syntax" is introduced to specify whether a .proto file
uses proto2 or proto3:// foo.proto syntax = "proto3"; message Bar {...}
If omitted, the protocol compiler will generate a warning and "proto2" will
be used as the default. This warning will be turned into an error in a
future release.We recommend that new Protocol Buffers users use proto3. However, we do not
generally recommend that existing users migrate from proto2 from proto3 due
to API incompatibility, and we will continue to support proto2 for a long
time. - Removal of field presence logic for primitive value fields, removal
-
Added support for map fields (implemented in proto2 and proto3 C++/Java/JavaNano and proto3 Ruby).
Map fields can be declared using the following syntax:
message Foo { map<string, string> values = 1; }
Data of a map field will be stored in memory as an unordered map and it
can be accessed through generated accessors.
C++
-
Added arena allocation support (for both proto2 and proto3).
Profiling shows memory allocation and deallocation constitutes a significant
fraction of CPU-time spent in protobuf code and arena allocation is a
technique introduced to reduce this cost. With arena allocation, new
objects will be allocated from a large piece of preallocated memory and
deallocation of these objects is almost free. Early adoption shows 20% to
50% improvement in some Google binaries.To enable arena support, add the following option to your .proto file:
option cc_enable_arenas = true;
Protocol compiler will generate additional code to make the generated
message classes work with arenas. This does not change the existing API
of protobuf messages and does not affect wire format. Your existing code
should continue to work after adding this option. In the future we will
make this option enabled by default.To actually take advantage of arena allocation, you need to use the arena
APIs when creating messages. A quick example of using the arena API:{ google::protobuf::Arena arena; // Allocate a protobuf message in the arena. MyMessage* message = Arena::CreateMessage<MyMessage>(&arena); // All submessages will be allocated in the same arena. if (!message->ParseFromString(data)) { // Deal with malformed input data. } // Must not delete the message here. It will be deleted automatically // when the arena is destroyed. }
Currently arena does not work with map fields. Enabling arena in a .proto
file containing map fields will result in compile errors in the generated
code. This will be addressed in a future release.
Python
- Python has received several updates, most notably support for proto3
semantics in any .proto file that declares syntax="proto3".
Messages declared in proto3 files no longer represent field presence
for scalar fields (number, enums, booleans, or strings). You can
no longer call HasField() for such fields, and they are serialized
based on whether they have a non-zero/empty/false value. - One other notable change is in the C++-accelerated implementation.
Descriptor objects (which describe the protobuf schema and allow
reflection over it) are no longer duplicated between the Python
and C++ layers. The Python descriptors are now simple wrappers
around the C++ descriptors. This change should significantly
reduce the memory usage of programs that use a lot of message
types.
Ruby
-
We have added proto3 support for Ruby via a native C extension.
The Ruby extension itself is included in the ruby/ directory, and details on
building and installing the extension are in ruby/README.md. The extension
will also be published as a Ruby gem. Code generator support is included as
part ofprotoc
with the--ruby_out
flag.The Ruby extension implements a user-friendly DSL to define message types
(also generated by the code generator from.proto
files). Once a message
type is defined, the user may create instances of the message that behave in
ways idiomatic to Ruby. For example:- Message fields are present as ordinary Ruby properties (getter method
foo
and setter methodfoo=
). - Repeated field elements are stored in a container that acts like a native
Ruby array, and map elements are stored in a container that acts like a
native Ruby hashmap. - The usual well-known methods, such as
#to_s
,#dup
, and the like, are
present.
Unlike several existing third-party Ruby extensions for protobuf, this
extension is built on a "strongly-typed" philosophy: message fields and
array/map containers will throw exceptions eagerly when values of the
incorrect type are inserted.See ruby/README.md for details.
- Message fields are present as ordinary Ruby properties (getter method
JavaNano
-
JavaNano is a special code generator and runtime library designed especially
for resource-restricted systems, like Android. It is very resource-friendly
in both the amount of code and the runtime overhead. Here is an 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.
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[].
See javanano/README.txt for details.
Protocol Buffers v3.0.0-alpha-1
Version 3.0.0-alpha-1 (C++/Java)
General
-
Introduced Protocol Buffers language version 3 (aka proto3).
When protobuf was initially opensourced it implemented Protocol Buffers
language version 2 (aka proto2), which is why the version number
started from v2.0.0. From v3.0.0, a new language version (proto3) is
introduced while the old version (proto2) will continue to be supported.The main intent of introducing proto3 is to clean up protobuf before
pushing the language as the foundation of Google's new API platform.
In proto3, the language is simplified, both for ease of use and to
make it available in a wider range of programming languages. At the
same time a few features are added to better support common idioms
found in APIs.The following are the main new features in language version 3:
- Removal of field presence logic for primitive value fields, removal
of required fields, and removal of default values. This makes proto3
significantly easier to implement with open struct representations,
as in languages like Android Java, Objective C, or Go. - Removal of unknown fields.
- Removal of extensions, which are instead replaced by a new standard
type called Any. - Fix semantics for unknown enum values.
- Addition of maps.
- Addition of a small set of standard types for representation of time,
dynamic data, etc. - A well-defined encoding in JSON as an alternative to binary proto
encoding.
This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and
Java. Items 6 (well-known types) and 7 (JSON format) in the above feature
list are not impelmented.A new notion "syntax" is introduced to specify whether a .proto file
uses proto2 or proto3:// foo.proto syntax = "proto3"; message Bar {...}
If omitted, the protocol compiler will generate a warning and "proto2" will
be used as the default. This warning will be turned into an error in a
future release.We recommend that new Protocol Buffers users use proto3. However, we do not
generally recommend that existing users migrate from proto2 from proto3 due
to API incompatibility, and we will continue to support proto2 for a long
time. - Removal of field presence logic for primitive value fields, removal
-
Added support for map fields (implemented in C++/Java for both proto2 and
proto3).Map fields can be declared using the following syntax:
message Foo { map<string, string> values = 1; }
Data of a map field will be stored in memory as an unordered map and it
can be accessed through generated accessors.
C++
-
Added arena allocation support (for both proto2 and proto3).
Profiling shows memory allocation and deallocation constitutes a significant
fraction of CPU-time spent in protobuf code and arena allocation is a
technique introduced to reduce this cost. With arena allocation, new
objects will be allocated from a large piece of preallocated memory and
deallocation of these objects is almost free. Early adoption shows 20% to
50% improvement in some Google binaries.To enable arena support, add the following option to your .proto file:
option cc_enable_arenas = true;
Protocol compiler will generate additional code to make the generated
message classes work with arenas. This does not change the existing API
of protobuf messages and does not affect wire format. Your existing code
should continue to work after adding this option. In the future we will
make this option enabled by default.To actually take advantage of arena allocation, you need to use the arena
APIs when creating messages. A quick example of using the arena API:{ google::protobuf::Arena arena; // Allocate a protobuf message in the arena. MyMessage* message = Arena::CreateMessage<MyMessage>(&arena); // All submessages will be allocated in the same arena. if (!message->ParseFromString(data)) { // Deal with malformed input data. } // Must not delete the message here. It will be deleted automatically // when the arena is destroyed. }
Currently arena does not work with map fields. Enabling arena in a .proto
file containing map fields will result in compile errors in the generated
code. This will be addressed in a future release.