[Checkers] IGJ Status

[Mahmood Ali]

Hi Mike,

I will break my response into two parts: IGJ status and case studies,  
and the inference tool.

I want to proceed my response with a clarification regarding the  
completeness of IGJ framework. There are two views on the completeness  
of a checker:
1. Based on the checker being a module that relies on the framework  
conforming to its exposed API.  I believe that the IGJ checker (and  
somewhat so as the Interned and NonNull) have reached that stage  
(module some heuristics and flow analysis inference).
2. Based on the checker being viewed as an application from the point  
of the user.  As you have experienced, the framework still has some  
bugs, at this time mainly due to Arrays.  In the last few weeks, I  
have been working on improving the checker to address that issues I  
experienced in my case study (like handling varargs and method  
invocation among other things).  I want to redo the case studies to  
see if the IGJ checker from this prospective is useable and correct.

In the next few weeks, I will work closely with Matt to identify what  
the problems with arrays are and try to fix them with him. Once this  
is done, I don't see much in the checkers agenda besides better  
documentation/refactoring/fixing found bugs/more testing (all of which  
are important though).

> (I think we may be able to report use of fewer annotations, too,  
> thanks to
> your method invocation inference.)
Actually, this also save some of the casts needed for toArray methods  
when they are supplied with the arrays, as it is declared as '<T> T[]  
toArray(T[])'.

We still may need to special case Collections.toArray() to make it  
return the type of the collection. That should be easy now. I will add  
this special casing this weekend. It would save us some casts.
On the other hand, the generated false positives, encourage the users  
to use the toArray with the type parameter which is more type safe.

>> 1. Investigating the value-added of IGJ.
>> [Doing case studies myself]
>> 2. Usability testing of IGJ
>> [Evangelizing others to use IGJ]
>>
> These two projects sound similar to me, with the only difference being
> whether you do the case studies yourself, or you find another user who
> wants to try the system.  Is that correct?  Your decision between  
> those
> probably depends on your confidence in its usability and whether you  
> want
> to focus on the type system or also evaluate the toolset.

They are similar in the sense that they teach us about the type system  
and its limitation and power in practice, however with a slight  
variation.  One of the ways to evaluate the type system is to see how  
it changes the engineering of new programs as opposed how to re-fit it  
on old ones. Our case studies are more of the latter, but I don't  
think that I will be writing much Java code in the next months (I will  
be working mainly with Scheme and C for the next year!!).

>> 4. Investigating ways to improve the type system.
>
> I think #1 and #2 should
> precede work on #4 in order to keep you focused on what really  
> matters.
I will wait on this, but flush out more ideas about it.

- Mahmood