Integer.MAX_SIZE (0x7FFFFFF) #2228

M java/core/src/main/java/com/google/protobuf/CodedInputStream.java
 Set DEFAULT_SIZE_LIMIT to Integer.MAX_SIZE (Was 64MB). This is how it was
 in pre-2.7.0 pb. Changed size check to an overflow-conscious test (as it
 is later in tryRefillBuffer (making sizeLimit a long was to disruptive).

M java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java
 Add two tests that echo tests recently added over in c++ to test parse
 of message sizes that are approach and are beyond the size limit.

* Uses build-helper-maven-plugin to add generated sources to the classpath
* Fixes an issue building with newer versions of the maven-compiler-plugin
  (See https://issues.apache.org/jira/browse/MCOMPILER-240)

Fixes #2269

[skip ci]

Change-Id: I1ba6f6372a08b5796570851336e1a548602f60da

Change-Id: I3ff47358e66965cab34736eed2a477ae29f02f61

[skip ci]

Change-Id: I1ba6f6372a08b5796570851336e1a548602f60da

Change-Id: I3ff47358e66965cab34736eed2a477ae29f02f61

gson 2.3 has internal bug that it doesn't work with some versions of maven.

gson 2.3 has internal bug that it doesn't work with some versions of maven.

Since Java 7, Strings produced with String.substring do not share byte arrays.

The default behaviour of throwing an exception remains

Turns out travis doesn't have the library dependencies to run a 32-bit
binary.

Change-Id: I5fadbcade2eb71c1e9ce21d90fa9459797df0e81

Turns out travis doesn't have the library dependencies to run a 32-bit
binary.

Change-Id: I5fadbcade2eb71c1e9ce21d90fa9459797df0e81

Change-Id: I991396ac6e51e32f3ab1daa501d625f34c3ecb04

Change-Id: Ib2bb5042deaabdf452d5be2ad1ce40d739ad8d1b

Also fixed javadoc errors.

[ci skip]

Change-Id: I43f7e04a53d1445dfa86db310bdb18ceb446398c

Currently some public API methods are defined in GenreatedMessage.java
and they have a generric return type:
  class GeneratedMessage {
    class Builder<BuilderType extends Builder<BuilderType>> {
      public BuilderType setField(...);
      public BuilderType setExtension(...);
    }
  }
With these definitions, the compiled byte code of a callsite will have
a direct reference to GeneratedMessage. For example:
  fooBuilder.setField(...);
becomes:
  ##: invokevirtual // Method Builder.setField:(...)LGeneratedMessage.Builder
  ##: checkcast     // class Builder

This will prevent us from updating generated classes to subclass a
different versioned GeneratedMessageV3 class in the future (we can't do
it in a binary compatible way).

This change addresses the problem by overriding these methods directly
in the generated class:
  class Foo {
    class Builder extends GeneratedMessage.Builder<Builder> {
      public Builder setField(...) {
        return super.setField(...);
      }
    }
  }
After this, fooBuilder.setField(...) will be compiled to:
  ##: invokevirtual // Method Builder.setField:(...)LFoo.Builder

The callsites will no longer reference GeneratedMessage directly and we
can change Foo to subclass GeneratedMessageV3 without breaking binary
compatiblity.

The downside of this change is:
  1. It increases generated code size (though it saves some instructions
     on the callsites).
  2. We can never stop generating these overrides because doing that
     will break binary compatibility.

Change-Id: I879afbbc1325a66324a51565e017143489b06e97

This includes all internal changes from around May 20 to now.