[Checkers] QualifierHierarchy

[Michael Ernst]

Artemus-

> The qualifier hierarchy is a bit confusing when you are using a type system
> that has multiple interacting annotations.
> 
> The public abstract method use 2 AnnotationMirrors. For the isSubtype, the
> spec says to return true iff anno1 is a sub-qualifier of anno2.
> This is unclear in situations where the annotations interact, and a single
> annotation can not be taken by itself.

You are correct about this limitation.

The Javadoc comments for QualifierHierarchy
(http://groups.csail.mit.edu/pag/jsr308/current/doc/checkers/types/QualifierHierarchy.html)
state:

  This assumes that any particular annotated type in a program is annotated
  with at most one qualifier from the hierarchy.

We chose to target this common case first, to keep the abstraction
manageable (for users and for implementers) in the common case.  We
recognize that there are valid reasons to build more complex type systems,
but don't have experience with enough of them to build that support in.
Your experience might help to inform an eventual design.


> These methods also do not include the
> actual type  the annotations are on;

Correct.

> e.g. @Constrained(UIResource.class)
> could indicate that the type cannot be assigned to any reference that does
> not implement the UIResource interface.

I'm a touch confused, because this this isn't an example of the first
phrase of the sentence.  "UIResource.class" is an argument to the
@Constrained annotation, not the the the annotations are on.  Did you mean
for your example to be "@Constrained UIResource", or were you making a
separate point?

                    -Mike