Re: [Clirr-devel] adding methods to interfaces

[<lak...@t-...>]

Simon Kitching wrote:

>Hi,
>
>In MethodSetCheck, the reportMethodAdded method uses:
>      final Severity severity = 
>	!newClass.isInterface() && 
>	(newClass.isFinal() || !newMethod.isAbstract())
>                ? Severity.INFO
>                : Severity.ERROR;
>
>
>This means that adding a method to an interface is reported as an ERROR.
>However the java spec section 13.5.3 says:
>
><quote>
>Adding a method to an interface does not break compatibility with
>pre-existing binaries
></quote>
>
>I've tested this, and this seems to be correct: there will not be a
>*linktime* error reported under any circumstances. However if I have
>code which implements the old interface, and I then pass this object to
>code that tries to invoke a new method, an AbstractMethodError runtime
>exception occurs.
>
>So I think that this should be a WARNING, not an error. What do you
>think?
>
>  
>

I think we could follow the same route that I'm currently investigating 
for source incompatibilies. I.e. the ApiDifference should not have only 
one severity field, but one field for each compatibility class 
(linktime, runtime, source).

In the meantime I think ERROR is OK - "clirr" stands for "//Client 
binaries must link and *run* with new //releases...". To me linktime and 
runtime errors are pretty much equivalent, either of them means I can't 
use the new version as a drop-in replacement because my application will 
bomb out with some exception sooner or later.

>-------------------------------
>
>I'm also somewhat puzzled by the remainder of the ternary expression
>too.
>
>Adding an abstract method to a class is indeed a problem, because
>subclasses can exist which don't have that method. But like the
>interface issue, I think this is a WARNING (runtime problem) rather than
>an ERROR (linktime problem).
>
>  
>

See above - I think differentiating between linktime and runtime errors 
is not very useful from the perspecive of a library user. Let's keep it 
at ERROR until we have the extended API available in the ApiDifference 
class.

>And why is it ok to add an abstract method to a final class? Final
>classes are never allowed to be abstract, so this shouldn't be possible
>as far as I know..
>
>  
>

Maybe it's because I've just recovered from the flu, but I don't 
understand your point here...

There are theoretically four combinations of final and abstract. One of 
them (abstract method in a non-final class) creates a compatibility 
problem and the code reports that correctly.

The remaining three cases do not create a compatibility problem. One of 
those remaining three cases (abstract method and final class) cannot be 
achieved with a correct java compiler - but that doesn't matter here, 
because it is still not a compatibility problem: there can't be any 
subclasses where the method is missing because the class is final. 
Reporting INFO in that case is OK, no?

Cheers,
Lars