binary-compatibility-validator
binary-compatibility-validator copied to clipboard
Should override functions be included in the API spec?
Adding or removing an override function is binary compatible in Java so why are these functions included in the public API spec? I suppose they are technically public or protected but it does add some extra work when making binary compatible changes.
The tool should check for covariant return types however but if the signature is identical to the parent signature it can be omitted from the spec.
Good point with covariant return types! Though it seems to be more complicated than that.
Consider the following scenario: I extend 3rd-party class A
(that is e.g. unstable), override all methods explicitly and ship it as my public API of class B
.
I am effectively protecting my class B
from ABI changes in class A
, making all its abstract/open methods my ABI. And it would be nice to still reflect this in compatibility-dump.
Also, it's still a good goal to keep BCV as simple as possible, knowing that ABI is a pretty subtle topic.
You are protecting but you’ll still have issues if you’re calling super
and the superclass removes a method.
My biggest concern is that you’ll think that you’re making a binary incompatible change when in fact you aren’t.
The unstable 3rd-party class scenario seems unusual compared to the scenario where 3rd-party classes are assumed stable and, as @ansman mentions, you don't want the false impression that you're breaking something when you're actually not.
I'm also not convinced you wouldn't want the heads-up from this tool that those functions are now becoming your own ABI.
final
overrides in non-final classes are another case similar to covariant returns types that should still be in the generated reference though.