To summarize the benefits of Java 8 lambdas over Java 1.1 lambdas: - Nicer, less bulky syntax. IDEs like IntelliJ already auto format/pretty Java 1.1 style lambdas, but it's nice not to rely on tools like this. - Cleaner VM implementation. Java developers don't read their byte code and don't care. There may be some modest performance benefits and it makes it easier to work with the byte code. - Native functional collections. There are third party functional collections for older Java (Functional Java), but it's good to have this built into the base SDK. - More awareness and community support.
Ricky, what was I hoping for? Good question. I guess they did what they can on this lambda issue. Simon, yes it's less than ideal that Java only has SAM (now called functional interfaces) rather than pure function types, so the following are completely separate types: Supplier<String> stringSupplier = () -> "supplier result"; Callable<String> stringCallable = () -> "callable result"; Casper, Java 8 lambdas are completely backwards compatible with Java 1.1 style lambda APIs. I don't see what else they could do without breaking backward compatibility. The final requirement on outer variable capture is there on purpose because it prevents a lot of common mistakes like this: http://blog.roboblob.com/2012/09/30/dot-net-gotcha-nr2-loop-variables-and-closures/ -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
