Are function types a requirement?
Alex.Buckley at Sun.COM
Wed Feb 17 18:13:50 PST 2010
You have summed up the situation perfectly.
Anonymous inner classes would be much better loved without the 'final'
gotcha. I would hate for lambdas to fall into the same "What were they
thinking?" bucket over a technically minor detail like function types.
Furthermore, function types in themselves still leave Doug needing
duplicate ParallelArrays to get fast primitive array implementations.
Counterpoint: one could say that function types + upgraded anonymous
inner classes (without the 'final' restriction) + lambda conversion
would be fine. No lambda expressions needed. No arguments over 'this'.
Compatible with adding method references.
Let's remember that this OpenJDK project is an experiment, with a small
mailing list (~150 people), and without interaction from many valued JCP
partners. So I don't see the need to throw out function types today,
barely six weeks after the project started being active.
Stephen Colebourne wrote:
> Recent threads have indicated the difficulties of adding function types
> to the language.
> - difficult/impossible to integrate with arrays (an omission that would
> certainly be a surprise to many I suspect)
> - difficult to integrate with varargs
> - difficult to implement (various strategies suggested)
> - difficult syntax choices (difficult to find something that is easy to
> read, given Java's painful checked exceptions)
> - debated invocation syntax - the func.() syntax
> One alternative is to omit function types from JDK 7, and only include
> conversion to SAM interface types. It would be a compile time error to
> declare a lambda expression/block that did not convert to a SAM.
> Function types could then be included in JDK 8 if a valid approach was
> available (ie. it gives the appearance of needing much more in depth
> study than the timescale allows)
> - reduces risk of making the wrong decision in the short JDK 7 time-frame
> - avoids all the issues above (AFAIK)
> - doesn't restrict adding function types later (we'd need some proof of
> - reduces the initial learning curve
> - doesn't tackle the problem of fork-joins excess of interfaces, which
> is declared as a major project goal
> - results in multiple, incompatible SAM interfaces for the same concept
> - no automatic handling of co/contra variance
> I therefore ask (in a positive way!) as to whether function types are a
> fixed requirement of project lambda? Or whether the SAM-conversion-only
> strategy would be considered for JDK 7? (My concern is to avoid the
> experience of generic wildcards where it was rather rushed in at the
> last minute by all accounts)
> I'm really looking for a simple answer from Alex rather than a debate on
More information about the lambda-dev