6723444: javac fails to substitute type variables into a constructor's throws clause

Maurizio Cimadamore Maurizio.Cimadamore at Sun.COM
Wed Jul 23 08:11:51 PDT 2008


Mark Mahieu wrote:
> Hi, Maurizio.
>
> On 23 Jul 2008, at 14:35, Maurizio Cimadamore wrote:
>>
>> The main issue here is that a JCNewClass node of the AST keeps only 
>> track of the constructor symbol (which means that we have only access 
>> to the 'formal' constructor, "<X extends Throwable> Hello(Foo<X> foo) 
>> throws X" in this case). Since the actual type of the constructor 
>> (the one with Exception in place of X) get lost during attribution, 
>> there's no way to recover that info at a later point during flow 
>> analysis.
>>
>
> Yes that matches my understanding.
>
>> My fix basically consists in storing the actual type of the 
>> constructor method inside the 'type' field of the constructor field 
>> stored inside the AST node.
>
> Hmm.  The Symbol held in the constructor field isn't unique for each 
> new class expression (unless it's an anonymous class), so changing its 
> type could cause problems.  For example, does the following compile 
> with that approach?
>
>
> public class Hello {
>     static class Foo<X> {}
>
>     <X extends Throwable> Hello(Foo<X> foo) throws X {}
>
>     public static void main(String[] args) throws Throwable {
> new Hello(new Foo<Exception>());
> new Hello(new Foo<Throwable>());
>     }
> }
>
>
> If I understood you correctly I think you'd get a 'cannot find symbol' 
> error on the second constructor invocation.  Or have I misunderstood?
This is one of the problem I had, but it can be easily solved by cloning 
the symbol and setting the type on the cloned symbol instead. My actual 
implementation compile your example. Only... I don't like it!!

Maurizio
>
>>
>> Regards
>> Maurizio
>>
>
> Regards,
>
> Mark
>




More information about the compiler-dev mailing list