[Checkers] <@ReadOnly Object> generic type (fwd)
mahmood at MIT.EDU
Wed Mar 26 11:49:04 EDT 2008
> 1. The proposed solution of treating class C<T> as shorthand for
> class C<T extends @Readonly Object>
> 2. There's a separate question of whether we should treat class C<T
> extends Object> as shorthand for class C<T extends @Readonly Object>
> I tend to lean toward doing so, mostly because Object has no methods
> mutable receiver, and so this treatment cannot cause a problem.
IMHO, this exposes a weakness in the Javari system (or at least as I
understand) and a superiority in IGJ.
For a type variable, I want to be able to say multiple things about
1. T could be anything. In traditional Java, I would specify as
simply as <T> which is a shorthand for <T extends Object>
2. T could only represent mutable references. In Javari, this should
be <T extends @Mutable Object> or <T extends Object>, since everything
is mutable by default (The suggested proposal will change this
behavior, but it's not a big deal).
3. T could only represent readonly references or readonly classes
(since Javari supports readonly classes). I don't know how to specify
that in Javari. <@ReadOnly T>? In IGJ, I cannot specify T to be a
readonly reference only, but I can make it extend @Immutable Object.
[You can replace Date with Object, in the previous items to specify
(To give credit where credit is due, I remember hearing David Glasser
or Jeff talking about this Javari property).
Also, I both issues in IGJ in a different way. I should have
documented that choice and/or discussed it with the group further. I
made Object and interfaces type element be of a PLACE_HOLDER type is a
wildcard that match any other IGJ annotation. It is not exposed to
the user, and used only internally in the checker.
My justitifcation was that Object and interfaces should be allowed to
be extended into immutable and mutable classes. While the interface
of List for example has mutating methods, I can still extend it to
create an immutable list. This is only in terms of the type element
and the first kind of declaration (IGJ actually makes C<T> into C<T
extends PLACE_HOLDER Object>). However, declaration of the second
kind actually desugered into List<E extends @Mutable Object> following
the default convention that anything is mutable by default.
> I suggested this proposal because treating Object specially feels
> wrong to
> me. I would rather find a rule that handles both Object and other
> for two reasons. First, it explains *why* Object is treated
> Second, it will preserve backward-compatibility in more cases, such as
> class C<T extends Comparable<T>>
I like this proposal. We will need to specify where the default
annotation (@Mutable) is not applicable if the user didn't specify it.
Matt and I were discussing having a representation to expose the
relationship between annotations. Currently, the checkers expose an
ordering over types (@Mutable Object to @ReadOnly Object), but it
seems that we should have the checkers expose an ordering over the
annotations too (Mutable to ReadOnly). In this last week (I forgot to
include in my progress report), I have been working on creating a new
GraphSubtypeRelation where the checkers would simply specify the
subtype graph of the annotations. It seems that this would benefit
Javari and the rest of checkers. While it can also be used for IGJ to
implement your proposal, I will still need to tweak it to make
@ReadOnly List<@Mutable Date> be a subtype of @ReadOnly List<@ReadOnly
Date> (which is not the case in Javari, I believe). Having this would
allow us to finally implement the earlier proposal regarding inserting
annotations from the tree hierarchy.
More information about the checkers