[Checkers] Skeleton Index Files

[Mahmood Ali]

Greetings,

Thanks for identifying some of these problems and separating the  
issues apart.

I would like to preface my reply with the following:

I don't want to necessary replace annotation file utilities, as a  
project.  I don't know if the code is reuseable or not.  However, my  
design goals of the index seem to be different from annotation file  
utilities goals.  Mainly in the following ways:
1. Checker Index (refer to the new proposed index) is human readable/ 
editable file, while the Utilities Index (refers to the index file as  
specified by the annotation file utilities specification) is designed  
to be edited with tools rather than persons.

2. Checker Index is meant to be used for type checking only, so would  
only contain qualifiers on Elements (class, method, fields). Utilities  
Index is more flexible to add annotations everywhere.

3. The Checker Framework, in my idea, won't actually insert the  
annotations into the classfiles or source.  In my proposal, the  
Checker framework would simply have a map of each element (method) and  
the corresponding type.  Whenever AnnotatedTypeFactory.fromElement is  
called it would check against the map and return the corresponding  
type if one exist.
The representation of Checker Index reflects this need, as we simply  
need a parser that constructs AnnotatedTypeMirror directly from the  
index file.  Utilities Index is very complex representation to  
actually achieve this.


> 2. It's annoying to remember to pass the right JDK for each checker.
>
> If a mechanism helps the compiler locating the annotation index file
> without requiring the user to specify it explicitly, the same  
> mechanism
> should work for locating stub libraries.

Not quite.  In my proposal, the index file can be one file in the same  
folder as the Checker, just like messages.properties, and that file  
would be included in the jar file.  The Framework would load that  
index file directly.

If we use the stub files, then the mechanism needs to be either  
impeded in the javac command, which is undesirable, or that the  
Checker Framework would need to append the jdk source location to the  
sourcepath, which I am not quite is possible.  Other mechanisms, like  
using sh aliases, aren't very good solutions as they are not portable.

> 3. Mahmood doesn't want to reuse the annotation file utilities.  He  
> prefers
> to write a new set of similar tools.
> Can you explain your reason for not wanting to use the existing tools?
It would be very nice for annotation-file-utilities to recognize the  
new format what ever it is.
>


> I have a slightly different proposal for the format of the new  
> annotation

> file.  My proposal is to use the same syntax as a Java file, with  
> all code
> bodies eliminated, but permitting identifiers such as parameter names.
I like your proposal.  I will write another email sometime earlier  
next week to discuss the pros/cons

> Another possible disadvantage is that the parsing of my proposed file
> format is more complicated than parsing of a simpler, less readable  
> format
> such as the one Mahmood proposes.  I don't think it will be a lot more
> complicated, since the two are fairly similar.
The main difference between the two, is that my proposal specifies the  
element and its corresponding type.  We would simply need a parser for  
the type and not the element as we can find it using  
Element.toString().equals comparision.  In your proposal, the parser  
needs to keep that information.

Also, dealing with import statements might be difficult.  In my  
proposal, we actually write the whole thing; which is what skeleton- 
generator class does anyway.

>> The index ... would only
>> contain the relevant methods for the checker (e.g. without any other
>> String methods).
>
> Would the index file permit @Default annotations at the level of a  
> package,
> class, etc., so that methods that are omitted nonetheless have their  
> type
> qualifiers specified?
@Default would be like any annotations that can show up anyway,  
including package and classes.  I haven't finalized the specification  
for classes yet and their extends and implements clauses.

- Mahmood