[Checkers] Declarative specification of qualifier hierarchy
telmo at MIT.EDU
Fri Mar 28 14:02:10 EDT 2008
Yes, all checkers need to implement their own type checking.
SimpleSubtypeRelation is not expressive enough for anything other than a
simple subtype relationship.
I do think extending a Relation class for each checker is better than
expressing the hierarchy through meta-annotations. A class that extends
SubtypeRelation doesn't need to express only subtype relationships per se;
as JavariSubtypeRelation uses it, it is just an abstract class from which
the relationship between annotations can be expressed. Encrypted/Plaintext
type qualifiers could be distinguished by a EPSubtypeRelation with the
appropriate isSubtype method that doesn't invoke the super method.
(Perhaps SubtypeRelation could be refactored with a new name,
TypeRelation, to clarify that it can do more than just specify a boolean
relation between annotations; it can express a boolean relation between
To put it in other way, the differences between the desired functionality
of SubtypeRelation and GraphSubtypeRelation are still not clear to me; and
I think each checker could express its allowed assignments by extending
some subclass of SubtypeRelation (including SubtypeRelation).
On Fri, 28 Mar 2008, Mahmood Ali wrote:
>> I'm not sure I agree with the need for a GraphSubtypeRelation.
> I beg to differ. I believe that GraphSubtypeRelation is a necessity, or at
> least that all checkers should re-implement their subtype checking, for the
> following reasons:
> 1. We don't have any unifying method for the checkers currently. Javari is
> using JavariSubtypeRelation which extends SubtypeRelation (which is not
> subclassed by any other class). NonNull and Interned checkers are using
> SimpleSubtypeRelation. IGJ is using its own thing within Checker.
> 2. SimpleSubtypeRelation cannot really be used for other types. It uses some
> hacks to get around issues related to boxing/unboxing and checking against
> 3. SubtypeRelation is horribly broken. It doesn't do anything clever about
> boxing/unboxing and doesn't handle type arguments properly. For example, it
> doesn't handle the following case (as tested by Javari)
> @Mutable List<@Mutable Date> l1 = null;
> @Mutable List<@ReadOnly Date> l2 = l1; // should emit error
> while l2 is not a subtype of l1.
> 4. isSubtype sometimes needs to do some more complicated work in preperation
> (unbox boxed type / call asSuperOf on lht), and uses different methods for
> comparing annotations (subtypes for raw type / identical for type argument).
> It will be extra nice to unify them.
> 5. It seems to me that we will have other types of annotations relations that
> aren't a subtype relationship as we have worked on. Consider the
> Encrypted/Plaintext type qualifiers that we are considering as a case example
> for the CustomChecker. They are not subtypes of each other, they are indeed
> in-conflict of each other. SubtypeRelationship (and
> SimpleSubtypeRelationship) shouldn't be able to handle this easily. As a
> side-note, CustomChecker assumes that the negative annotation is a supertype
> of the positive annotation, which is false ("Plaintext/Encrypted",
> Trusted/Tained, etc).
> - Mahmood
More information about the checkers