[Checkers] Anonymous Constructors

[Mahmood Ali]

> Another solution, by the way (that you should perhaps note) is for the
> javac compiler to copy the annotations to the generated constructors.
> [...] What do you see as the tradeoffs between the two?  Should we  
> change
> the compiler rather than the framework?

The type qualifiers annotations should be copied to the constructors.   
I can go either way about whether the compiler or the framework that  
should this job.

__Having the compiler to do it__
Pros:
1. Stay adherent to the proposal and make type qualifiers in the byte  
code available for purely bytecode analysis tools.
2. The framework becomes smaller and more portable (as we wouldn't  
need to port this functionality all around).  It would ease writing  
other frameworks too.

Cons:
1. The compiler doesn't differentiate between annotations and type  
qualifiers.  It may be undesirable to copy non-qualifier annotations.   
Consider having @Author (@WrittenAt or any annotations being a meta- 
data for the method), if the compiler copies such annotations, a naive  
annotation processor might over-estimate the number of methods such  
author wrote.

2. The framework needs to add extra qualifiers anyway to the first  
argument of anonymous constructors (when creating anonymous  
constructors for the extended class is an inner class).  Specifically,  
it needs to add the root qualifier.  Consider the following:

class Test {
   class InnerClass { }
   static void useInnerClass() {
     Test t = null;
     t.new InnerClass() { }; // <-- line at interest
}

The anonymous new class instantiation expression gets re-written by  
the compiler to be:

         new InnerClass(t<*nullchk*>){

             (Test x0) {
                 x0.super();
             }
         };

In such cases, the framework would need to insert the root qualifier  
to 'Test x0' so that IGJ and Javari wouldn't assume that argument is  
mutable by default.

Detour: Also, note how the resulting tree is an invalid tree.  We  
actually needed to modify the compiler so it would output '(Test x0)'  
instead of '(.Test x0)'.  In the current design when having type- 
checking occurs before attribution and javac type checking, we have  
two type checking phases: one before running the visitors invoked  
specifically by SourceChecker.process, and another one by Javac after  
the completion of processing phase.  The second attribution and type- 
checking, the compiler may issue invalid tree error.  Matt corrected  
some of the problems, and we haven't seen those errors for awhile now  
=).

__Having the Framework to do it__
Pros:
1. While prototyping, it is easier to do it in the framework, since we  
are most familiar with this.  Our edits to the compiler would have  
higher likelihood with conflicting with Sun changes.
2. The framework needs to deal with the first argument in such  
constructors anyway.
3. The compiler knows which annotations are type qualifiers and which  
aren't.

Cons:
1. Those inserted annotations won't be available to other tools or  
static tools.  I suspect that Javarifier doesn't care about them  
anyway since it would infer them easily from finally invoked  
constructor signature.

Regards,
Mahmood

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/mailman/private/checkers/attachments/20080701/a6f7a081/attachment.htm