Fix compatiblity issues.
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
Showing
Please
register
or
sign in
to comment