- 06 Dec, 2016 1 commit
-
-
Caleb Welton authored
-
- 02 Dec, 2016 1 commit
-
-
Michael Stack authored
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.
-
- 18 Nov, 2016 1 commit
-
-
Adam Cozzette authored
-
- 11 Nov, 2016 1 commit
-
-
Time authored
-
- 04 Nov, 2016 1 commit
-
-
Christopher Tubbs authored
* 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)
-
- 20 Oct, 2016 1 commit
-
-
nmittler authored
Fixes #2269
-
- 10 Oct, 2016 6 commits
- 23 Sep, 2016 3 commits
- 21 Sep, 2016 1 commit
-
-
Bo Yang authored
gson 2.3 has internal bug that it doesn't work with some versions of maven.
-
- 20 Sep, 2016 4 commits
- 16 Sep, 2016 1 commit
-
-
Patrick Strawderman authored
Since Java 7, Strings produced with String.substring do not share byte arrays.
-
- 08 Sep, 2016 1 commit
-
-
Dave Protasowski authored
The default behaviour of throwing an exception remains
-
- 02 Sep, 2016 1 commit
-
-
Jisi Liu authored
-
- 31 Aug, 2016 1 commit
-
-
Feng Xiao authored
Turns out travis doesn't have the library dependencies to run a 32-bit binary. Change-Id: I5fadbcade2eb71c1e9ce21d90fa9459797df0e81
-
- 01 Aug, 2016 1 commit
-
-
Feng Xiao authored
Turns out travis doesn't have the library dependencies to run a 32-bit binary. Change-Id: I5fadbcade2eb71c1e9ce21d90fa9459797df0e81
-
- 25 Jul, 2016 1 commit
-
-
Jisi Liu authored
-
- 19 Jul, 2016 2 commits
- 18 Jul, 2016 2 commits
- 14 Jul, 2016 2 commits
-
-
Feng Xiao authored
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
-
Feng Xiao authored
-
- 13 Jul, 2016 2 commits
- 03 Jul, 2016 1 commit
-
-
Otto Kekäläinen authored
-
- 01 Jul, 2016 1 commit
-
-
chezRong authored
-
- 29 Jun, 2016 1 commit
-
-
Adam Cozzette authored
This includes all internal changes from around May 20 to now.
-
- 20 May, 2016 1 commit
-
-
Feng Xiao authored
-
- 17 May, 2016 1 commit
-
-
Feng Xiao authored
-
- 11 May, 2016 1 commit
-
-
Feng Xiao authored
-