Raw nots from Simon Ritter's talk.

We had support for some functional programming in JDK 1.0: anonymous inner classes. Lambdas do it much more cleanly.

You can use lambdas where ever the type is a Functional Interface. It has a single abstract method: accept.

A lambda looks like a method, but it is not associated with a class. Therefore you can't call it a method.

(parameters) -> body

There was a lot of debate of whether it should be =>.

Lambdas are closures over values, not types. This means state cannot be modified in a lambda. This means you can only refer to variables in the surrounding scope, they have to be effectively final. Effectively means either explicitly marked final, or it's value cannot be changeable.

Method references let us reuse a method as a lambda expression. Three different ways of using them. Static method. Instance method of an arbitrary type. Instance method of an existing type.

Performance implications. Anonymous inner classes force the compiler to generate funny class names, type pollution, must be loaded at runtime. Originally, lambdas were implemented this way. Better way is to use invokedynamic. Original idea of invokedymanic was to improve performance of dynamically typed languages on the JVM. Defers implementation of the Lambda to the runtime. It was the first thing added to the JVM bytecode since Java 1.0.

java.lang.LambdaMetaFactory returns an instance of the lambda functional interface type. Can divide lambdas into two groups. Non-capturing lambdas: no surrounding scope being used; simple conversion to static method. Capturing lambdas: does use surrounding scope: static method with captured variables prepended as parameters or synthetic instance method of class using Lambda.

Went over some impl performance differences between lambdas and anonymous inner classes. Also for capture vs. instantiation of anonymous inner classes. The latter has heap implications. Unused lambdas have no overhead. Non-capturing lambdas automatically optimise. Method references are slightly more optimal. -XX:+TieredCompilation gives beter lambdas. This is the default.

Alonso Church, the Lambda Calculus (1936). A way of having a mathematical definition for having functions and calling them. He was Alan Turing's PhD advisor.

Java programmers are typically imperative programmers. Functional programming is not imperative: no side effects. Lambda calculus and Turing machines are equivalent. What can we do only using Lambda expressions?