[Checkers] Index File Brainstorming

[Mahmood Ali]

Greetings,

This week, I am planning to get an index file parser working.  I don't  
not anticipate much trouble as I already have most of the code ready  
for my original proposal.

This email contains some of the ideas and consideration that I am  
thinking about.  It would be nice to get some input about some of  
these decisions.

Note: Interface as used in the class interface (exported methods and  
fields declarations) not the java Interface.

========== Index Format =========

An index file could specify the type annotations in the interfaces (no  
local variables, casts, etc) in independent files separate from the  
classfiles or the source file.  One index file should be able to  
specify multiple interfaces (some with name conflicts).

The index file should look as close as necessary to the java file  
format.  Personally, I think that we can safely ignore the import  
statements.  The index file for the interning type system is (within  
brackets are optional and ignored).

package java.lang;
[public final] class String {
   [public] @Interned String intern();
}

As second example, consider the following declaration for IGJ:
package java.util;
@I
[public] interface List<E> extends @I Collection<E> {
   void add(E [e]) @Mutable;
   ...
}

For me, I think that the import statements are unnecessary.  The  
important are only necessary to eliminate the ambiguity of the java  
type, but we can already determine the type by inspecting the elements  
within the class being examined.  The imports might be necessary only  
for the annotations themselves.

Some issues to consider:
1. How should we specify inner classes, like Map.Entry?  I favor  
having their own declaration, like

class Map.Entry { ... }

instead of

class Map { class Entry { ... } }

2. I would really like to have some pattern matching syntax.   
Something like:

class * {
   String toString() @ReadOnly;
   void clear() @Mutable;
}

Any thoughts?

========== Implementation Issues =========

I am a bit troubled by the possible overhead of parsing the Index  
file.  Ideally, we would parse the method/field declaration (or the  
enclosed class) on the fly and on demand.  I suspect that parsing the  
entire JDK index file would add a significant overhead when compiling  
a simple file for example.  I would like it to be similar to the  
loading mechanism of java.

Possible solution:
Have two phase parsing:
- In the first phase, we index all the classes and their location in  
the file (using a quick parser)
- When a class type is queried, we examine if we have it in the index  
file, and if it is we parse that region and cache the results.   
Subsequent queries to the same file would be directed to the cache  
instead.

Does this sound reasonable?

Regards,
Mahmood