[Checkers] Skeleton Index Files
mahmood at MIT.EDU
Wed Jul 2 14:09:17 EDT 2008
Thanks for identifying some of these problems and separating the
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
> 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
> 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
> 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
> 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
> class, etc., so that methods that are omitted nonetheless have their
> 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.
More information about the checkers