grpc build treates them as errors and such issues (protobuf change
breaks grpc) has been reported repeatedly. For example:
https://github.com/google/protobuf/issues/1813
Change-Id: I077c4557cf3effd5195f88802c38999b884edc30
1. Set JAVA_HOME so mvn can pick up the correct java version.
2. Remove jdk6 tests. It has been broken for a while and remain undetected as
mvn is actually using java 7 to build the code. Given that we have
set -source and -target to 6 in the pom.xml and the built .jar
should be usable by java 6, having a dedicated java 6 test doesn't
seem necessary (assuming very few Java 6 users want to compile protobuf
Java from source).
Change-Id: I4f14da772632df3e47801f180198242b306c3f0f
This change will help us separate binary support into
separate files, because we only refer to binary serialization
functions in the actual binary serialization paths.
When building into frameworks, the generated code doesn't always have direct
access to the proto internals. Instead of opening up the access, just use the
public method to fetch the correct oneof.
Fixes https://github.com/google/protobuf/issues/1789
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
We now just perform the optimization within AddRange itself.
This is a breaking change in terms of "drop in the DLL", but is
source compatible, which should be fine.
