[Checkers] IGJ Status
mahmood at MIT.EDU
Wed Mar 19 09:44:01 EDT 2008
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
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
> probably depends on your confidence in its usability and whether you
> 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
I will wait on this, but flush out more ideas about it.
More information about the checkers