Programming languages are not for machines to execute.

They are for programmers to think in.

Languages are a conversation with a compiler to turn our thoughts into something a machine can execute. One of the chief complaints about Java from people who come to it from other languages (or leave it for other languages) used to be that it forces a certain mental model on the programmer (i.e. everything is a class).

I'm not going to weigh in on whether that's good or bad: everything is trade-offs. But Java 8 lambdas allow programmers to think in terms of functions, which is something you previously could not do in Java.

It's the same thing as a procedural programmer learning to think in terms of classes when they come to Java: you see them gradually move from classes that are glorified structs and have 'helper' classes with a bunch of static methods and move on to something that more closely resembles a rational OO design (mea culpa).

If you just think of them as a shorter way to express anonymous inner classes then you are probably not going to find them very impressive in the same way that the procedural programmer above probably didn't think classes were any great improvement.

Saving lines of code can be viewed as a new feature, if it enables you to write a substantial chunk of logic in a shorter and clearer manner, which takes less time for others to read and understand.

Without lambda expressions (and/or method references) Stream pipelines would have been much less readable.

Think, for example, how the following Stream pipeline would have looked like if you replaced each lambda expression with an anonymous class instance.

List<String> names =
    people.stream()
          .filter(p -> p.getAge() > 21)
          .map(p -> p.getName())
          .sorted((n1,n2) -> n1.compareToIgnoreCase(n2))
          .collect(Collectors.toList());

It would be:

List<String> names =
    people.stream()
          .filter(new Predicate<Person>() {
              @Override
              public boolean test(Person p) {
                  return p.getAge() > 21;
              }
          })
          .map(new Function<Person,String>() {
              @Override
              public String apply(Person p) {
                  return p.getName();
              }
          })
          .sorted(new Comparator<String>() {
              @Override
              public int compare(String n1, String n2) {
                  return n1.compareToIgnoreCase(n2);
              }
          })
          .collect(Collectors.toList());

This is much harder to write than the version with lambda expressions, and it's much more error prone. It's also harder to understand.

And this is a relatively short pipeline.

To make this readable without lambda expressions and method references, you would have had to define variables that hold the various functional interface instances being used here, which would have split the logic of the pipeline, making it harder to understand.

Internal iteration

When iterating Java Collections, most developers tend to get an element and then process it. This is, take that item out and then use it, or reinsert it, etc. With pre-8 versions of Java, you can implement an inner class and do something like:

numbers.forEach(new Consumer<Integer>() {
    public void accept(Integer value) {
        System.out.println(value);
    }
});

Now with Java 8 you can do better and less verbose with:

numbers.forEach((Integer value) -> System.out.println(value));

or better

numbers.forEach(System.out::println);

Behaviors as arguments

Guess the following case:

public int sumAllEven(List<Integer> numbers) {
    int total = 0;

    for (int number : numbers) {
        if (number % 2 == 0) {
            total += number;
        }
    } 
    return total;
}

With Java 8 Predicate interface you can do better like so:

public int sumAll(List<Integer> numbers, Predicate<Integer> p) {
    int total = 0;

    for (int number : numbers) {
        if (p.test(number)) {
            total += number;
        }
    }
    return total;
}

Calling it like:

sumAll(numbers, n -> n % 2 == 0);

Source: DZone - Why We Need Lambda Expressions in Java

There are many benefits of using lambdas instead of inner class following as below:

• Make the code more compactly and expressive without introducing more language syntax semantics. you already gave an example in your question.

• By using lambdas you are happy to programming with functional-style operations on streams of elements, such as map-reduce transformations on collections. see java.util.function & java.util.stream packages documentation.

• There is no physical classes file generated for lambdas by compiler. Thus, it makes your delivered applications smaller. How Memory assigns to lambda?

• The compiler will optimize lambda creation if the lambda doesn't access variables out of its scope, which means the lambda instance only create once by the JVM. for more details you can see @Holger's answer of the question Is method reference caching a good idea in Java 8? .

• Lambdas can implements multi marker interfaces besides the functional interface, but the anonymous inner classes can't implements more interfaces, for example:

  //                 v--- create the lambda locally.
  Consumer<Integer> action = (Consumer<Integer> & Serializable) it -> {/*TODO*/};
  

To answer your question, the matter of fact is lambdas don’t let you do anything that you couldn’t do prior to java-8, rather it enables you to write more concise code. The benefits of this, is that your code will be clearer and more flexible.

One thing I don't see mentioned yet is that a lambda lets you define functionality where it's used.

So if you have some simple selection function you don't need to put it in a separate place with a bunch of boilerplate, you just write a lambda that's concise and locally relevant.

Yes many advantages are there.

• No need to define whole class we can pass implementation of function it self as reference.
  • Internally creation of class will create .class file while if you use lambda then class creation is avoided by compiler because in lambda you are passing function implementation instead of class.
• Code re-usability is higher then before
• And as you said code is shorter then normal implementation.

Lambdas are just syntactic sugar for anonymous classes.

Before lambdas, anonymous classes can be used to achieve the same thing. Every lambda expression can be converted to an anonymous class.

If you are using IntelliJ IDEA, it can do the conversion for you:

• Put the cursor in the lambda
• Press alt/option + enter