hg: lambda/lambda/langtools: Next round of implementation reflecting the latest 'State of the Lambda' draft; implemented features are:

[Peter Levart]

I belive I caught another one. This time the conversion to SAM interface with overriden method using covariant return produces invalid code. If I run this:


package closures;

public class Closures 
{
  public interface ObjectF { Object invoke(); }
  public interface StringF extends ObjectF { String invoke(); }

  public static void say(StringF stringFunc) {
    System.out.println("stringFunc says: " + stringFunc.invoke());
  }

  public static void say(ObjectF objectFunc) {
    System.out.println("objectFunc says: " + objectFunc.invoke());
  }

  public static void main(String[] args) 
  {
    say(#{ "Hello" });
  }
}


... I get:


Exception in thread "main" java.lang.AbstractMethodError: closures.Closures$1.invoke()Ljava/lang/String;
        at closures.Closures.say(Closures.java:9)
        at closures.Closures.main(Closures.java:18)


Regards, Peter

On 07/26/10, Maurizio Cimadamore wrote:
> My bad,
> I misread your example - what you are trying to do it's ok (except from 
> the fact that you are using function types, that are not supported in 
> the current draft ;-) ). Your program is rejected because of a straight 
> bug in the prototype. I will be fixing this shortly.
> 
> Thanks for the headsup
> Maurizio
> 
> On 26/07/10 18:27, Maurizio Cimadamore wrote:
> > On 26/07/10 17:10, Peter Levart wrote:
> >> public class Closures
> >> {
> >>    public static #int() twice(final int value)
> >>    {
> >>      return #{ value + value };
> >>    }
> >>
> >>    public static #int() twice(final #int() func)
> >>    {
> >>      return #{ func.() + func.() };
> >>    }
> >>
> >>    public static void main(String[] args)
> >>    {
> >>      System.out.println(twice(22).());
> >>
> >>      #int() fortyFour = twice(#{22});
> >>      System.out.println(fortyFour.());
> >>
> >>      //System.out.println(twice(#{22}).());
> >>    }
> >> }
> > Thanks for the report,
> > I was partially aware of the issue. The fact is that the current 
> > prototype does not support the lambda invocation syntax anymore (that 
> > is, we removed '.()'). As a result, lambda expression should only 
> > appear 'bare' in a method call/assignment context.
> >
> > I think that, however, the compiler should at least generate a better 
> > error message in this case; I managed to handle most cases, but not 
> > all yet.
> >
> > Thanks
> > Maurizio
> 
>