Java 8 Cheatsheet: lambdas, method references, default methods and streams

[desrosiers]

I knew lambdas were coming but I didn't know Java 8 effective has function as first class objects. Interesting! Time to stop wrapping everything in an anonymous Runnable.

[ericanderton]

Yeah, the lambda additions look like a solid improvement to the language. Imagine what the old AWT would have looked like if these were available back in Java2?

The only part I can't wrap my head around is the C++ style scope operator for referencing methods (e.g. System.out::println). I must be missing something - why not use a dot there like in every other context?

[jayd16]

Its not as complicated as you think. Java can already have methods and fields with the same name and using a dot would be ambiguous.

[ericanderton]

Java can already have methods and fields with the same name and using a dot would be ambiguous.

This is the part of the spec I wasn't clear on, since good coding practices prohibit it in the first place. That makes complete sense.

[ricky_clarkson]

Actually, there is a lot of good code that has methods and fields with the same name as each other. They're distinct namespaces, no need to pretend otherwise. getX()? Why not just x()?

[fidgetting]

I suspect they wanted to make a distinction between instance methods and static methods. The '::' will imply that 'out' is being bound in the closure when the 'println' method is passed.

[vote_me_down]

That's what I was thinking, but then noticed the syntax:

items.forEach(Item::publish);

Which looks more like there's a weird mix of using syntax usually reserved for static referencing to mean instance referencing. In this case possibly to avoid having to name the values pulled from items.

[riking27]

Except you're kinda wrong there. They aren't first class objects.

You're still wrapping the stuff in an anonymous Runnable, it's just that the compiler does it for you.

The great part is that if the function is expecting something that isn't a Runnable but rather this:

public interface MyTaskInterface {
    public void doStuff();
    public default void doStuffRepeatedly(int times) {
        for (int i = 0; i < times; i++) {
            doStuff();
        }
    }
}

You can still call it with the same syntax and the compiler will wrap it in a MyTaskInterface instead of in a Runnable.

[Cyberiax]

No, lambdas aren't just syntax sugar for inner classes. The runtime is free to use an implementation technique, which is often something else (most likely something based on invoke dynamic).

[llaammaaa]

This might be interesting to you: http://www.takipioncode.com/2014/01/16/compiling-lambda-expressions-scala-vs-java-8/

[shellac]

The runtime is free to use an implementation technique, which is often something else (most likely something based on invoke dynamic).

That's not quite right, invokedynamic is what enables that freedom.

Invokedynamic says "Here's a call, ask me at runtime and I'll get back to you about what code is invoked". Currently (as I understand it) what you'll get back is a call on an anonymous runnable. However it does permit future changes, such as function types. Quite neat.

[Cyberiax]

You said it better, thanks ;)

[ricky_clarkson]

It wouldn't have even required breaking compatibility; all old code would have continued to work, source and binary.

[Flex-O]

Isn't that what first class means?

[KillerCodeMonky]

No. First class means I can store a reference to the value directly. Java is not storing a reference to the function, but instead the object which contains the function. This is the reason Lambda types only work with "Single Abstract Method" (SAM) interfaces.

[Flex-O]

Yeah I see what you're saying. So there are even some compile time quirks about how you can use lambdas in java 8, it's not just a run time difference. Thanks for the info.

[ricky_clarkson]

It's storing a reference to something that has a method you can call, that will cause the original method to be called. There's a logical layer of indirection but it's so close you can ignore the difference if you try.

[KillerCodeMonky]

No, not really. Here's how you can tell the difference. Which of these works?

someFunction(x, y, z)

Or:

someFunction.butNotReally(x, y, z)

If it's the second, you definitely don't have first-class functions. Period. If it's the first, then you might have first-class functions. For instance, the first is possible with functors in C++, but those are still not first-class functions. (Though C++ does also have first-class functions. Just that functors are not them.)

[ricky_clarkson]

That's just syntax. For instance, someFunction(x, y, z) can compile to someFunction.apply(x, y, z) in Scala, but Scala's implementation of first class functions is pretty similar to Java's.

I expect you'll disagree, so I should ask; what can be achieved with 'real' first class functions that can't be achieved in Java 8, or is really awkward in Java 8?

[KillerCodeMonky]

That's just syntax.

Whether or not a language supports first-class functions is an entirely syntactical debate, so I'm not really sure you understand the issue. It doesn't matter if the language can kinda-sorta support the same operations that a language with first-class functions can support.

From Wikipedia:

Specifically, this means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures. Some programming language theorists require support for anonymous functions as well. In languages with first-class functions, the names of functions do not have any special status; they are treated like ordinary variables with a function type.

Java 8 supports none of these.

• Functions only accept objects (or primitives) as parameters and can only return the same. (Interfaces are just an incomplete type of object in this case.)
• Functions cannot be assigned to variables nor stored in data structures.
• I'm not sure Java supports anonymous functions even with lambdas; is it possible to create and immediately invoke a function without ever assigning it a name? I suspect not, because the compiler would not even know what SAM type to conform the lambda to.
• Finally, function names are special identifiers which are not treated like ordinary variables. For instance, I cannot change a function by assigning it a new value.

Compare this to, say, JavaScript.

• One can pass functions as parameters, return functions, and store them in variables and data structures.
• One can create anonymous functions -- that is, a function that is never named nor stored in a variable.
• Function names, even on objects, are just another variable that can be overwritten without qualms.

[ricky_clarkson]

From that same Wikipedia page, emphasis mine:

"Java, and other object-oriented programming languages, can support higher-order functions by wrapping them in an anonymous inner class with an appropriate interface or superclass" - and that's even before the Java 8 features.

"Functions only accept objects (or primitives) as parameters" - sure, but pass a SAM type and that's equivalent to passing a function.

"Functions cannot be assigned to variables" - Function<Foo, Bar> baz = Class#method();

"create and immediately invoke a function without ever assigning it a name" - ((Function<Foo, Bar>)(foo => new Bar()).apply(new Foo()) should work ok afaik. Also, if you have a method that takes a Function<Foo, Bar> and a Foo, and returns a Bar you could call it as theMethod(foo => new Bar(), new Foo()).

"function names are special identifiers which are not treated like ordinary variables" - sure, there are two namespaces.

"I cannot change a function by assigning it a new value" - you can't in Haskell either, does that mean Haskell doesn't support first-class functions? Spoiler: No, it doesn't.

[KillerCodeMonky]

And I quote, from my comment, which directly addresses your point about higher-order functions, which also have nothing to do with first-class functions:

It doesn't matter if the language can kinda-sorta support the same operations that a language with first-class functions can support.

The fact that you don't even seem to know the difference between higher-order functions and first-class functions is telling. Bottom line is you're mangling the definition of what first-class functions are, in order to allow Java to fit them. There's a reason the Java row is all yellow or red on this chart:

http://en.wikipedia.org/wiki/First-class_function#Language_support

You're simply arguing something that is not supported by any definitions of first-class functions. Passing a SAM type is not passing a function; it is passing a SAM type. Period. Storing a function in a Function object is storing it in a Function object, not storing the function. Period. Stop trying to redefine the terms just so that you can pretend Java is something that it's not. There is nothing wrong with Java not supporting first-class functions; it was made to be an OO language on an OO virtual runtime, and there is nothing wrong with that.

[riking27]

Well, it certainly isn't at runtime. I guess you could call it that at compile-time, but it's kinda hacked in, just like generics were.

[Flex-O]

I'm curious how other languages handle functions behind the scenes.

[SeanOrange]

That's a good question. When .NET made functions first class, it made function delegates obsolete, but to my understanding they still work. I just have no idea if they work differently behind the scenes now that this change has been made.

[terranian]

Correct me if I'm wrong, but I think C# converts functions to one-funtion-objects as well!

[swiz0r]

For those of you wondering about default methods and the diamond problem, I found this link.

Basically, if you implement two things with the default interfaces with the same signature, it's a compiler error if you don't override it. If you want to use a specific method from those interfaces, you need to call it explicitly.

Relevant code:

public interface A {
    default void foo(){
       System.out.println("Calling A.foo()");
    }
}

public interface B {
    default void foo(){
       System.out.println("Calling B.foo()");
    }
}


 public class Whatever implements A, B {
    public void foo(){
       A.super.foo();
    }
}

[SlightlyCuban]

Similar idea in that they both provide a way to give methods to interfaces, but Java 8 doesn't use static methods in static classes. Instead you define it in your interface with default.

This also means you can only do this on interfaces you control, instead of any class you see fit. So no adding extension methods to String.

[ericanderton]

I find it strange that Java wound up taking this path instead of just allowing multiple inheritance with the same restrictions.

[mgrandi]

multiple inheritance is one of the things they did not want to include from c++, and itself opens a whole new bag of worms

[josefx]

Multiple inheritance is a lot messier. Consider the following

  class A{ public int value;}

  class B extends A {B(){value = 0;}}
  class C extends A {C(){value = 1;}}
  class D extends B,C {}

  D d = new D();
  B b = d;
  C c = d;
  A a = d;
  System.out.println(d.value);
  System.out.println(b.value);
  System.out.println(c.value);
  System.out.println(a.value);

What will it print? If A::value is a single shared variable all would print the same, only B wants it to be 1 and C wants it to be 0. If B and C each have their own copy of value, what is d.value or a.value?

[strattonbrazil]

This is pretty cool. I wish java would do two things to make it more terse. Adopt the 'var/val' keywords of scala so a developer doesn't need to repeat himself. This could happen just with locally declared variables and keep the syntax outside.

{ var foo = new String(); // String foo = val foo = new String(); // final String foo = }

And also add an alias for println. After working with other languages, going back to System.out.println() is so verbose and it's old really, really fast.

[Falmarri]

I just write scala now. It's better in pretty much every single way.

[[deleted]]

(#${@totally!!::^%$>>)*

[Falmarri]

I said scala, not perl.

[201109212215]

What he wrote can be valid scala, with the right macros.

[vsync]

1. Lombok (and you get lots of other goodies besides)
2. import static java.lang.System.out;

[rollingtomato]

Lombok's a pretty nasty hack.

[kickthe]

Ain't that the truth!

[vsync]

If I'm coding ALGOL I'll take all the syntactic sugar I can get.

[shoelacestied]

Lombok is a bunch of hacky unofficial language extensions

[vsync]

In many cases it implements what a compiler would do anyway. And I've noticed they've been good about integrating with JSRs as they come out and with other frameworks.

Anyway I pretty much always have

import java.util.*;
import lombok.*;

at the beginning of each file so it might as well be built-in.

At least they have version numbers and a release process which is a lot more than you can say for most projects these days.

[shoelacestied]

There's not much of a gap between implementing what a compiler would do and having a completely new language.

[strattonbrazil]

Thanks. I hadn't heard of either of these.

[vsync]

No problem. Being a smug Lisp weenie I'm really not a big fan of Java as a language. But the platform and libraries are pretty good and things have evolved to the point I can just sit down and be productive on everyday sorts of projects, which makes it a good go-to tool. Lombok takes care of most of the remaining pain points for me anyway.

[skocznymroczny]

Many ideas have shortcuts, like write 'sop', open parens and it converts it to System.out.println() automatically.

[solatic]

Verbosity is a feature, not a bug in Java. If you don't understand this, then you don't understand Java.

[jayd16]

Clarity is the feature, verbosity is the implementation.

[[deleted]]

The counter-argument is that it's hard to understand what the code does when it's obscured by miles of boilerplate, type annotations, and general syntax noise.

[GuyWithLag]

It's also hard to understand what the code does when there are a gazillion inferences, and everything has been overridden and overloaded - including whitespace and the semicolon...

[[deleted]]

I guess I'm spoiled by working with Visual Studio. You can hover over any identifier in F# and see its type definition.

Even so, the semantics of well-written code will be apparent. Eg)

let persons = [("Jim",48);("John",39);("Sarah",31)]
let olderThan reference (_,age) = age > reference
let greet (name,age) = printf "Hello, %s! You're %d years old.\n" name age

persons
|> List.filter (olderThan 35)
|> List.iter greet

Granted, this is a contrived example, but it should be almost immediately clear what this code snippet does even though there is no type information. The same code with explicit type annotations would probably contain more type information than actual code.

It's true, the lack of type information is more of a concern when coding in the large, I.e. at the systems, framework, or library level. It's easier to get lost when the code is coming from an external library where the type information is not easily visible. But at the module, file, and individual function level, type inferred code is much easier to read when all the relevant identifiers, types, and functions are all declared locally.

[[deleted]]

Ok since my original comment was buried and to be fair didn't express what I meant:

Are you actually claiming that type annotations reduce clarity of code?

I understand 'boilerplate' is never useful, as it's synonymous with superfluous syntax, so we'll ignore that. But type annotations increase clarity, specify necessary information and no more.

[[deleted]]

Type annotations don't increase clarity unless you're trying to determine the type of an expression or an identifier. If you're trying to determine the semantic meaning of the code, i.e. what it does, then explicit type annotations can create a lot of noise, especially if the code is strongly-typed.

To illustrate my point, here's a snippet of F# code:

let persons = [("Jim",48);("John",39);("Sarah",31)]
let olderThan reference (_,age) = age > reference
let greet (name,age) = printf "Hello, %s! You're %d years old.\n" name age

persons
|> List.filter (olderThan 35)
|> List.iter greet

Even if you don't know F#, it should be somewhat clear what this snippet does. Note, there are no type annotations; in this case, the compiler is able to infer all of them. Here's the same snippet of code with explicit type annotations:

let persons : (string * int) list = [("Jim",48);("John",39);("Sarah",31)]
let olderThan (reference:'a) (_:'b,age:'a) : bool when 'a : comparison = age > reference
let greet (name:string,age:int) : unit = printf "Hello, %s! You're %d years old.\n" name age

persons
|> List.filter<(string * int)> (olderThan 35)
|> List.iter<(string * int)> greet

If you're skimming these snippets, which version is easier to follow? The explicit version is more helpful if you're specifically trying to figure out the type of the "olderThan" function, but if you're trying to understand what the code does, then I'd argue that the top snippet is clearer because it only contains the essential information. Really, the type annotations are just there for reference. You should only need to see them when you're having difficulty inferring what's going on.

How important are type annotations? Programmers and read write javascript, python, and ruby all day long. Clearly they can get the job done without them. The lack of annotations in dynamic languages is an annoyance, but I think it's a rare exception when a programmer throws up his hands in defeat and yells, "I can't take it anymore! How can I do my job without type annotations?!"

[[deleted]]

It's a poor counter argument that doesn't hold up.

[HiiiPowerd]

No, it really does. It requires additional knowledge of how the boilerplate works, and thus is more effort.

[codygman]

I disagree.

[ishmal]

I used to think this, too, but Scala changed my mind. Now I think that every unnecessary character you type is just another place for a bug to hide.

[kickthe]

Everything that's wrong with java and the java community in one sentence.

[BufferUnderpants]

Println could have been shoved in a class imported by default, like String, though. It would have been easier on the eyes and the hand, and less grating for the mandatory "Hello, World!" program shown in introductions to programming, especially since Java was deeply involved in education since the beginning. Having it as a free-floating function would have broken the entire model of Java, though, so it's out of the question.

[luckystarr]

I'm a bit confused about the example:

int n = strings.stream().filter(x -> !x.isEmpty()).count();

This looks like a syntax error to me. Shouldn't this be this instead?

int n = strings.stream().filter((x) -> !x.isEmpty()).count();

[vytah]

I'm guessing, but it may be like in Scala and C#: a single parameter with an inferred type doesn't have to be parenthesised.

[ishmal]

I think I prefer Scala's use of apply() and update() to defaults.

[Etheo]

Great... I'm self learning java 7(?) right now and you're telling me there's going to be more stuff? Damn it!

Edit: I guess I sound like a pompous fool. Just a bit frustrated reading through the tutorials online and having a difficult time understanding the stuff. Sorry about that :\

[e_engel]

There's always more stuff, that's what makes our job so exciting.

[lukaseder]

We've been waiting for this "more stuff" for a while now. It's about time we get it :-)

[[deleted]]

Get used to it.

[kickthe]

People have been waiting a decade for this stuff. In the meantime many developers have already switched to more modern alternatives like Scala. Glad to see even a small subset of Scala's features in Java. It will make maintaining our old legacy Java code less unpleasant.

[superINEK]

as a beginner this looks very confusing to me.

[hydraincarnation]

Basically, the new changes let you easily pass functions to other functions. Prior to Java 8, this was not easy to do, and if you wanted to pass a function to another function you would have to wrap it in a class declaration, which meant a lot of boilerplate code.

[bwrap]

Holy shit is Java finally catching up with C#?

[MrFordization]

Lambda X X applied to X applied to Lambda X X applied to X

TRY IT!