protobuf/java
Paul Yang 7f3e237071 Merge 3.2.x branch into master (#2648)
* Down-integrate internal changes to github.

* Update conformance test failure list.

* Explicitly import used class in nano test to avoid random test fail.

* Update _GNUC_VER to use the correct implementation of atomic operation
on Mac.

* maps_test.js: check whether Symbol is defined before using it (#2524)

Symbol is not yet available on older versions of Node.js and so this
test fails with them. This change just directly checks whether Symbol is
available before we try to use it.

* Added well_known_types_embed.cc to CLEANFILES so that it gets cleaned up

* Updated Makefile.am to fix out-of-tree builds

* Added Bazel genrule for generating well_known_types_embed.cc

In pull request #2517 I made this change for the CMake and autotools
builds but forgot to do it for the Bazel build.

* Update _GNUC_VER to use the correct implementation of atomic operation on Mac.

* Add new js file in extra dist.

* Bump version number to 3.2.0

* Fixed issue with autoloading - Invalid paths (#2538)

* PHP fix int64 decoding (#2516)

* fix int64 decoding

* fix int64 decoding + tests

* Fix int64 decoding on 32-bit machines.

* Fix warning in compiler/js/embed.cc

embed.cc: In function ‘std::string CEscape(const string&)’:
embed.cc:51:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   for (int i = 0; i < str.size(); ++i) {
                                ^

* Fix include in auto-generated well_known_types_embed.cc

Restore include style fix (e3da722) that has been trampled by
auto-generation of well_known_types_embed.cc

* Fixed cross compilations with the Autotools build

Pull request #2517 caused cross compilations to start failing, because
the js_embed binary was being built to run on the target platform
instead of on the build machine. This change updates the Autotools build
to use the AX_PROG_CXX_FOR_BUILD macro to find a suitable compiler for
the build machine and always use that when building js_embed.

* Minor fix for autocreated object repeated fields and maps.

- If setting/clearing a repeated field/map that was objects, check the class
  before checking the autocreator.
- Just to be paranoid, don’t mutate within copy/mutableCopy for the autocreated
  classes to ensure there is less chance of issues if someone does something
  really crazy threading wise.
- Some more tests for the internal AutocreatedArray/AutocreatedDictionary
  classes to ensure things are working as expected.
- Add Xcode 8.2 to the full_mac_build.sh supported list.

* Fix generation of extending nested messages in JavaScript (#2439)

* Fix generation of extending nested messages in JavaScript

* Added missing test8.proto to build

* Fix generated code when there is no namespace but there is enum definition.

* Decoding unknown field should succeed.

* Add embed.cc in src/Makefile.am to fix dist check.

* Fixed "make distcheck" for the Autotools build

To make the test pass I needed to fix out-of-tree builds and update
EXTRA_DIST and CLEANFILES.

* Remove redundent embed.cc from src/Makefile.am

* Update version number to 3.2.0-rc.1 (#2578)

* Change protoc-artifacts version to 3.2.0-rc.1

* Update version number to 3.2.0rc2

* Update change logs for 3.2.0 release.

* Update php README

* Update upb, fixes some bugs (including a hash table problem). (#2611)

* Update upb, fixes some bugs (including a hash table problem).

* Ruby: added a test for the previous hash table corruption.

Verified that this triggers the bug in the currently released
version.

* Ruby: bugfix for SEGV.

* Ruby: removed old code for dup'ing defs.

* Reverting deployment target to 7.0 (#2618)

The Protobuf library doesn’t require the 7.1 deployment target so
reverting it back to 7.0

* Fix typo that breaks builds on big-endian (#2632)

* Bump version number to 3.2.0
2017-01-31 09:17:32 -08:00
..
compatibility_tests Use latest maven-compiler-plugin (2.6.0) 2016-11-04 02:11:55 -04:00
core Merge 3.2.x branch into master (#2648) 2017-01-31 09:17:32 -08:00
lite Use latest maven-compiler-plugin (2.6.0) 2016-11-04 02:11:55 -04:00
util Merge 3.2.x branch into master (#2648) 2017-01-31 09:17:32 -08:00
pom.xml Merge 3.2.x branch into master (#2648) 2017-01-31 09:17:32 -08:00
README.md Fix spelling in strings and comments 2016-07-03 15:26:04 +03:00

Protocol Buffers - Google's data interchange format

Build Status

Copyright 2008 Google Inc.

This directory contains the Java Protocol Buffers runtime library.

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 (see the toplevel README.md). 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.

The above instructions will install 3 maven artifacts:

  • protobuf-java: The core Java Protocol Buffers library. Most users only need this artifact.
  • protobuf-lite: The lite version of core Java Protobuf Buffers library. It is a subset of the core library and is used together with the 'lite' code generator flag to reduce generated code size for mobile.
  • protobuf-java-util: Utilities to work with protos. It contains JSON support as well as utilities to work with proto3 well-known types.

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 and only describes how to install the core protobuf library (without the util package).

  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=core/src/main/java -I../src
    ../src/google/protobuf/descriptor.proto

  3. Compile the code in core/src/main/java using whatever means you prefer.

  4. Install the classes wherever you prefer.

Compatibility Notice

  • Protobuf minor version releases are backwards-compatible. If your code can build/run against the old version, it's expected to build/run against the new version as well. Both binary compatibility and source compatibility are guaranteed for minor version releases if the user follows the guideline described in this section.

  • Protobuf major version releases may also be backwards-compatbile with the last release of the previous major version. See the release notice for more details.

  • APIs marked with the @ExperimentalApi annotation are subject to change. They can be modified in any way, or even removed, at any time. Don't use them if compatibility is needed. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use experimental APIs, unless you repackage them (e.g. using ProGuard).

  • Deprecated non-experimental APIs will be removed two years after the release in which they are first deprecated. You must fix your references before this time. If you don't, any manner of breakage could result (you are not guaranteed a compilation error).

  • Protobuf message interfaces/classes are designed to be subclassed by protobuf generated code only. Do not subclass these message interfaces/classes yourself. We may add new methods to the message interfaces/classes which will break your own subclasses.

  • Don't use any method/class that is marked as "used by generated code only". Such methods/classes are subject to change.

  • Protobuf LITE runtime APIs are not stable yet. They are subject to change even in minor version releases.

Documentation

The complete documentation for Protocol Buffers is available via the web at:

https://developers.google.com/protocol-buffers/