Java 8 Lambdas

'sorted()' doesn't really act like that, does it - taking in a comparator function?<p>It's much better to have comparator functions for the most common types baked in, and use projection to select a list of fields to use to compare with.<p>Comparator functions are very easy to get wrong. The example given here - ".sorted((a, b) -&#62; a.getValue() - b.getValue())" - won't work properly when the calculation wraps around.

Finally... and they even infer the type! Positively surprised. I will stick to Scala, though.

Would have been a big deal - if they introduced 10 years ago

The idea of 'default methods' looks quite disturbing. It seems to allow implementation of some methods inside interfaces. Which is against the basic idea of interface, isn't it? Correct me if I'm wrong, but multiple inheritance problems form C++ are now going to be a brand new feature in Java.

I was recently at a Java conference where Juergen Hoeller (of Spring fame) was a keynote speaker. In one of his talks he said something like "Once again, Java is solving yesterday's problems". The moment he said that, I thought to myself "Yes! So true!". The day before, Angelika Langer gave a talk on Lambdas in Java 8. I watched as the other developers listened with half-opened mouths (and some of them, with confused expressions on their faces) and wondered why, instead of bolting features other languages have had for decades onto Java (potentially leading to another fiasco like generics), Oracle doesn't instead continue to work on the JVM to give an even better support for languages that already do have these concepts (by, for example, providing support for TCO).

I don't know how I feel about interface defaults. Why is that more important than say declared properties or unsigned types?

I do not understand how this really any different that what we already have with anonymous classes/interfaces. If we have to continue to define interfaces for our lambdas then we might as well continue to use anonymous classes and remove the final restriction (that's completely backward compatible). The final restriction wasn't required in the original design of anonymous classes before the community freaked out over memory allocation of primitives. The reason closures are a pain in Java is having to meet the static typing declarations using interfaces for our anonymous classes. The whole point to this was to create a compact syntax for declaring methods that take lamdas as parameters without resorting to interfaces.<p>I also wish that default mechanism could be extended to existing classes as well so we could add methods to classes because the real question is what are the API changes to collection, File, etc with respect to the addition of lambdas. The places where Java has fallen short in the past is the API (Collection.join? Collection.map, Collection.reduce, new File( String... paths), etc).

It kinda sucks that you still have to declare an interface in order to pass functions around.

Will you be able to <i>return</i> lambdas or just <i>create</i> them as function inputs? (I guess you can write a method which takes an object of interface X and returns it, but do you have to do this for every interface you want to use, or would there be a universal reify() method? Is there a universal interface which would allow these to be proper first-level functions?)<p>If there are competing lambda interfaces, does the system fail at compile-time?

I'm curious to see what the implications are for other JVM languages given the promise of more efficient byte code.

Looks like they took a page from the Groovy language

Nice - only 5 years late though.

Hopefully no one with any sense will use these features.

Congratulations to the Java-programmers for getting a feature that virtually every other OOP language has had for about 10 years.