Question

UPDATE : Back in the days, it was just a compilation level problem with maven.

The issue concerns the @Override annotation and super interfaces.

It’s a simple as it gets really the problem is that the @Override annotation is not scoped up to the upper interfaces …

Here is a bit of simple code to understand the problem :

public abstract interface CrudDao<T>
{
    void update(T bean);

    T get(Object... pk);

    void delete(Object ...pk);

    T create(T bean);
}



public interface BeanDao extends CrudDao<Bean>
{
    Bean moreSpecificGetMethod();
    void moreSpecificUpdateMethod();
}

public class BeanDaoImpl implements BeanDao {

    @Override
    public void update(Bean bean){}

    @Override
    public Bean get(Object... pk){}

    //... Rest of the methods 
}

The compiler says the methods should be created in the BeanDao interface. Why is it not resolving the methods from the super interface ?

Answer 1

The compiler and the @Override annotation processor are just fine. During compilation with javac (on the command line), the following message is listed for the update method of BeanDaoImpl class:

update(info.example.Bean) in info.example.BeanDaoImpl cannot implement
update(T) in info.example.CrudDao; attempting to assign weaker access
privileges; was public

and the reason is because the update method in CrudDao is in fact public. According to the Java Language Specification:

Every method declaration in the body of an interface is implicitly public.

And on making the BeanDaoImpl.update method public, the error message goes away. The same holds good for similar error messages from other methods.

There is also the problem with the Eclipse project settings. Just because you are using JDK
1.6 to run Eclipse, you need not automatically have the compiler not complain about @Override annotation processing. You’ll need to set the Compiler compliance level of the project to 1.6, in your Java Compiler panel of your project settings. Having a value of 1.5 will result in the Eclipse annotation processor complain about unimplemented methods, when in fact, you those methods have been implemented, but declared in a superinterface, as in your case.

The problem with the compiler compliance level settings is partly due to the initial @Override specification – it was restricted to superclasses alone and did not include interfaces as a supertype. This was fixed in Java 6, but the documentation was not updated. The compiler compliance level of 1.5 get the Eclipse annotation processor to treat @Override annotated methods as those requiring existence in the superclass, and not in a supertype.