[JSR308] Proposal: Multiple Instance of same Annotation, Annotation Inheritance

[Niko Matsakis]

> Look, the current definition of annotations was also keeped simpler,
> to avoid complications.
> And now you propose to extend it, because you lack some features.
> In the future, someone else will need multiple inheritance (for a very
> good reason), and will ask to
> extend annotations again - the java will be changed again.

Good point.  I guess that I could reformulate the inheritance section  
to try to follow interface inheritance more closely.

According to the Java Language Specification section 9.4.1:

> It is possible for an interface to inherit several methods with  
> override-equivalent signatures (§8.4.2). Such a situation does not  
> in itself cause a compile-time error. The interface is considered to  
> inherit all the methods. However, one of the inherited methods must  
> must be return type substitutable for any other inherited method;  
> otherwise, a compile-time error occurs (The throws clauses do not  
> cause errors in this case.)

Therefore, we would make a similar rule regarding the properties/ 
methods of annotation types.  Since all methods on annotation types  
take no arguments, their signatures are trivially override- 
equivalent.  Therefore, you can combine inherit multiple properties  
with the same name so long as one of them has a "most specific" return  
type that is substitutable for all the others.  I could not find the  
precise definition of when a type is "substitutable" for another,  
perhaps it refers to the return type substitution of 8.4.5?  I guess  
that here I would simply to reproduce the behavior of interfaces,  
which I believe must also resolve the return type of a multiply- 
inherited method in such a scenario.

However, there is one additional wrinkle that occurs with annotations  
that do not occur with interfaces: default values.  The simplest rule  
here would be to say that at most one inherited method can supply a  
default value.  Alternatively, any number can supply default values  
but they must all have the same type and value.

The same rule would then apply to "overriding" members declared in sub- 
annotation-types: in other words, you can redeclare a property from a  
supertype, but the return type and default value must be compatible as  
described above.


regards,
Niko Matsakis