Inverse annotation inheritance issue with generic interfaces

Lukas Magel luke-mail at
Thu Nov 12 00:55:41 UTC 2015


I am currently working on a JAVA EE web project and have been 
experiencing a compiler behavior which I don't know how to interpret.

In our code we define interfaces like the following:

public interface SampleInterface<T extends A> {

     public void sampleMethod(T t);


as well as an implementing class:

public class Main implements SampleInterface<B> {

     public void sampleMethod(B t) {


and the corresponding annotation:

public @interface SampleAnnotation {


Where Class B extends A. All classes are compiled using the OpenJDK7 
compiler. If I use Reflection to retrieve all methods of the Main class 
at runtime and print each method with its annotations I get the 
following list of methods:

class Main

public void Main.sampleMethod(A)

public void Main.sampleMethod(B)

The compiler will assign the annotation to the method declaration of the 
interface although the annotation is only declared in the implementing 
class. I cannot reproduce this behavior with the Oracle Java Compiler or 
the Eclipse JDT Compiler. If I compile the example with one of the two 
compilers the resulting program will yield the following result:

class annotation.Main

public void annotation.Main.sampleMethod(annotation.A)

public void annotation.Main.sampleMethod(annotation.B)

The JRE type (Oracle, OpenJDK) that the program is executed with has no 
influence on the result.

My actual question is whether this behavior is intended or not because 
it causes quite some issues with our JAXRS REST implementations. All 
REST classes each implement an interface like the one above and are 
annotated with multiple annotations to allow the container to identify 
endpoints at runtime. The JAXRS framework uses reflection to determine 
possible method candidates at runtime and will happily accept both the 
generic and the special method since both of the carry the annotations.

I can also provide an example project if necessary.


More information about the compiler-dev mailing list