[Checkers] IGJ And Type Inference

[Jaime Quinonez]

Mahmood,

> Yes, I didn't mean that supporting partially annotated code would  
> require either approach. However, I was highlighting the two uses of  
> any type inference system and claiming that they require some what  
> different user experience:
> 1. bytecode support:
> - binary libraries are usually either fully annotated or not.  It's  
> useless for a vendor to distribute a partially annotated binary.
> - Users simply want to use the type inference tool for binary files  
> just so that their own code compiles properly.  Personally, I will  
> not debug the output of the inference tool for such system unless  
> they impact my own code annotation in unexpected ways.
> - It is OK for to simply output the annotation in a different index  
> file.  As long as my code compiles and it's a matter of an extra  
> argument for compiling, I wouldn't care about how the annotations  
> are represented.
>
> 2. Source support:
> - It is usually partially annotated.
> - I expect the use to interact with the type inference within an IDE.
> - Requires support of iterative process.  Command-line commands  
> aren't quite good in this.
> - Annotations should really go into the source directly and not a  
> separate index file.  It's OK to have the index file as an  
> intermediate representation and automate the process of insertion to  
> source.  As a user of the tool, I wouldn't like to spend time simply  
> copying annotations to the source.  I would like to see the  
> annotations on code mainly for the next modules, and it's couter- 
> productive to consult the seperate index file everytime I develop  
> new code.
>
> If the annotation file format allows for insertion into the source  
> directly. That's great. Otherwise, I wouldn't use it.
>

These are good points, and are worth thinking about.  I suspect an IDE  
could just use a combination of the compiler, a bytecode tool and the  
annotation file utilities to quickly infer and insert annotations into  
the source code, although the delay may be significant and would not  
provide a nice user experience.

Also, just to make sure you're aware of this, the annotation file  
utilities are currently here:

http://groups.csail.mit.edu/pag/jsr308/annotation-file-utilities/

Note that they haven't been updated in a very long time, because there  
really isn't anything that can be done with them until the classfile  
specification changes.

>
>>> 2. I believe that it is highly desirable (yet not quite important)  
>>> that the type inference tool does not load the classes.
>> What do you mean by 'load' exactly?
> I mean that it wouldn't call ClassLoader.loadClass().  This is not a  
> memory requirement, but I think that it's desirable, but not  
> necessary *required*, to be able to annotate a class that the JVM  
> depends on (e.g. java.util.Stack, java.lang.Object), or a class that  
> requires jni native linking without getting UnsatisfiedLinkError.
>
> That excludes using the javac compiler and the checker framework.  I  
> assume that Soot doesn't do that.
>

Ah, I see.  Yes, Soot reads every class it analyzes, up to and  
including Object, from .class files on the filesystem, according to a  
command-line classpath argument.  This means you can annotate any  
arbitrary class.  More importantly, at least for Javarifier, you *  
have * to annotated JDK classes.  Even if Javarifier worked on the  
JDK, you don't want to have to keep redoing that work.  Reading the  
JDK from stub classes also allows you to make small changes to the  
results and then use the modified library.

Jaime