Should override functions be included in the API spec?

[ansman]

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.

[ansman]

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.

[qwwdfsad]

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.

[ansman]

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.

[drewhamilton]

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.