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)
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
