[Checkers] <@ReadOnly Object> generic type (fwd)

[Mahmood Ali]

Hi,

> 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  
> with
> 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  
Javari:
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  
the subtree]

(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  
> classes,
> for two reasons.  First, it explains *why* Object is treated  
> specially.
> 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.

Regards,
Mahmood