[Checkers] Skeleton Index Files

Mahmood Ali mahmood at MIT.EDU
Wed Jul 2 02:23:03 EDT 2008


Greetings,

Today, while I am trying to address multiple issues here and and  
there, I got to work on having an index file and annotated type parser  
to be used by the framework instead of the method stubs.

Currently, the checkers use skeleton files for the JDK and they are  
meant to be used for compilation but not for running the code.  Users  
need to pass the JDK location through -sourcepath command to the jdk.   
This is undesirable for two reasons:
1. It's a bit annoying to link to the JDK and remember to pass the  
right JDK for each checker.
2. The skeleton files might contain public static final fields that  
get set to values other than the actual values.  The compiler may  
inline such values wrongly in the bytecode, hence affecting the  
runtime behavior of the program.

The proposed solution is that each compiler would have a text file  
with an index in a format similar to:

----------------------------
# possible index file for the Interning type system
# class name (possible extends and implements clauses)
java.lang.String

# Each line specifies the element of the method or field
# In this case, we are annotating the method 'intern()'
#
# the user specifies the type in the following way:
# For methods:  [< type variables >] ( [ param types ] ) { return type  
| void } : [ receiver annotations ]
# example for String.intern()

intern()	-	() @Interned java.lang.String:
----------------------------

(we can easily change the syntax)

Automatically, each checker would load its own index annotation file  
and use the resulting type instead of the annotated type resulting  
from parsing the JDK methods.  The index can be small so it would only  
contain the relevant methods for the checker (e.g. without any other  
String methods).

I have another class that generates the necessary files with un- 
annotated types and users only need to add the necessary annotations.   
We can include the class in the distribution and have the framework  
recognize another argument for index files.  Users can then simply  
have annotation index files for each library rather than using  
annotation-file-utilities or having stub classes for each binary and  
each checker they want to use.

Any suggestions? Recommendations?

Regards,
Mahmood

P.S. I realize that this is not in my TODO items and I have other  
important issues.  Unfortunately, I got sucked into working on it once  
I started writing a simple parser for annotated types.  I will work on  
this maybe next week or later.




More information about the checkers mailing list