Closure conversion vs silly type parameter

[Neal Gafter]

Looks like a bug.  Thanks for reporting it!  I'll tell you when it's fixed.

Regards,
Neal

On Tue, May 13, 2008 at 7:37 PM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080513/fbefd43f/attachment.html