Closure conversion vs silly type parameter

Mark Mahieu mark at twistedbanana.demon.co.uk
Tue May 13 19:37:44 PDT 2008


This one has me scratching my head a bit.  The following (rather odd)  
class compiles successfully despite there being a checked exception  
thrown which is never caught or declared to be thrown in the method  
signatures:


public class Hmmm {

     public static void main(String[] args) {
         foo() {
             throw new Exception();
         }
     }

     static <T extends {==> void}> void foo(T block) {
         block.invoke();
     }
}


Interestingly, the following version, which assigns the closure  
literal to a variable of the corresponding function type first, fails  
to compile (which is as I'd expect).


public class Hmmm2 {

     public static void main(String[] args) {
         { => void throws Exception} f = {=> throw new Exception(); };
         foo(f);
     }

     static <T extends {==> void}> void foo(T block) {
         block.invoke();
     }
}


Reading the closure conversion and function type subtyping rules  
again, I can't see why one would be allowed and the other not... any  
clues as to what I'm missing here?


Mark




More information about the closures-dev mailing list