Overriding a default method

Brian Goetz brian.goetz at oracle.com
Thu Aug 9 08:46:33 PDT 2012


Most of the "what if" questions about default methods can be answered by analogy to methods in classes.  So, turning your question back around:

"If a new method were added to a class in JDK 8, and that method exists in a pre-existing subclass, should the compiler provide any sort of informational diagnostic, in the event that the collision was unintentional?"  

We have a lot of experience with which to answer this question: no.  The way Java has always worked is that if method name and signatures match, it is the same method.  (The same happens when there are identical method signatures in two interfaces that are inherited by some type; they are "merged" and the collision is assumed to be intentional.)  

Many of the "scary" situations that arise with default methods actually have always been possible with abstract classes.  The difference is at most a quantitative one; it is possible this situation might come up "more often" going forward.  

I don't think the answer is new warnings for what is essentially an old problem.  However, there is an initiative underway to improve the accuracy of @since Javadoc tags.  If we had complete and reliable @since tags, it becomes practical for code auditing tools to be able to warn you of situations like the one you raise, such as with a "library upgrade pre-flight tool" that would warn you when changes in libraries might affect the inheritance characteristics of your classes.  


On Aug 9, 2012, at 7:56 AM, Zdeněk Troníček wrote:

> Hi,
> 
> if a new method is added to an existing interface in JDK 8, e.g. skip() to
> Iterator:
> 
> public interface Iterator<E> {
>  boolean hasNext();
>  E next();
>  void remove();
> 
>  void skip(int i) default {
>    for (; i > 0 && hasNext(); i--) next();
>  }
> }
> 
> it may happen that existing implementations have already a method of the
> same name. This method overrides the default method which is ok if it is
> intentional. However, unintentional overriding may lead to severe bugs
> when the method has different semantics.
> Do you plan to emit a warning at compile time, for example, when a class
> overrides a default method and @Override is missing?
> 
> Z.
> -- 
> Zdenek Tronicek
> FIT CTU in Prague
> 
> 
> 
> 



More information about the lambda-dev mailing list