Closure conversion vs silly type parameter

[Neal Gafter]

FYI: this may be a symptom of an existing bug in javac.  See
http://bugs.sun.com/view_bug.do?bug_id=6638712

Regards,
Neal

On Tue, May 13, 2008 at 11:00 PM, Neal Gafter <neal at gafter.com> wrote:

> 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/20080526/f896dddc/attachment.html