The Java 8 Revolution: Lambdas and Streams

Core Mechanics: Lambda Expressions and Functional Interfaces A functional interface is an interface with exactly one abstract method. Runnable (one method: run()), Comparator<T> (one abstract method: compare()), and ActionListener (one method: actionPerformed()) all qualify, and all of them existed before Java 8 — what Java 8 added was a syntax for implementing one of these interfaces without writing a class at all. A lambda expression is that syntax: (parameters) -> expression or (parameters) -> { statements }. The compiler looks at the target type — the functional interface the lambda is being assigned to or passed as — and generates an implementation of that interface's single abstract method using the lambda's body. Comparator<Employee> byName = (e1, e2) -> e1.getName().compareTo(e2.getName()); compiles to something that behaves exactly like an anonymous Comparator implementation, but without the five lines of ceremony around it.

The @FunctionalInterface annotation, also new in Java 8, is a compiler assertion: it causes a compile error if the annotated interface ever ends up with more or fewer than one abstract method. It is optional — any interface with exactly one abstract method works as a lambda target with or without the annotation — but it is good practice on your own interfaces, because it turns an easy mistake ("I added a second method and broke every lambda that implemented this interface") into an immediate compile error instead of a confusing one far from the cause.

Rather than ask every developer to define their own single-method interfaces for every situation, Java 8 shipped java.util.function with four interfaces that cover the overwhelming majority of real use cases, and these four names are worth memorizing because they appear constantly throughout the Streams API and beyond:

Interface	Method	Signature shape	Typical use
Function<T, R>	apply(T) -> R	takes one value, returns another (possibly different type)	map() in streams
Predicate<T>	test(T) -> boolean	takes one value, returns true/false	filter() in streams
Consumer<T>	accept(T) -> void	takes one value, returns nothing (does something with it)	forEach() in streams
Supplier<T>	get() -> T	takes nothing, returns a value	lazy value creation, orElseGet()

There are variants for two-argument versions (BiFunction<T,U,R>, BiConsumer<T,U>), and primitive specializations (IntPredicate, ToDoubleFunction<T>) that avoid the cost of boxing a primitive into its wrapper class on every call — a detail that matters more than it looks in a stream processing millions of elements, since boxing allocates an object on the heap for every single primitive value that passes through a generic interface.

Lambdas can capture variables from their enclosing scope, but only effectively final ones — a local variable that is assigned exactly once is eligible for capture even without the explicit final keyword, but a variable reassigned anywhere in the enclosing method cannot be captured, and the compiler rejects it with an error at the capture site. This restriction exists because a lambda may genuinely outlive the method it was created in — stored in a field, passed to another thread, scheduled for later execution — and Java has no mechanism for a lambda to share a live, mutable local variable with its enclosing method the way, say, a closure in JavaScript can. What gets captured is a snapshot of the reference (for objects) or the value (for primitives) at the time the lambda is created, not a live link back to the variable.

A common point of confusion: a lambda is not the same thing as an object of some new "lambda class." Under the hood, the JVM translates each lambda expression into a call to invokedynamic, a bytecode instruction added specifically to support this translation efficiently, which at runtime generates a lightweight class implementing the target functional interface — but that generation happens once per call site, lazily, and is deliberately different from (and cheaper than) how anonymous inner classes used to compile, where every anonymous class became its own .class file on disk at compile time.

import java.util.function.*;

public class LambdasAndFunctionalInterfaces {

    // A custom functional interface. The annotation is optional but makes
    // the "exactly one abstract method" contract explicit and compiler-checked.
    @FunctionalInterface
    interface Discount {
        double apply(double price);
    }

    public static void main(String[] args) {
        // --- Lambda targeting a custom functional interface ---
        Discount tenPercentOff = price -> price * 0.9;
        System.out.println(tenPercentOff.apply(200.0)); // 180.0

        // --- The four workhorse interfaces from java.util.function ---

        // Function<T, R>: takes a value, returns a (possibly different) value.
        Function<String, Integer> wordLength = s -> s.length();
        System.out.println(wordLength.apply("lambda")); // 6

        // Predicate<T>: takes a value, returns true/false.
        Predicate<Integer> isEven = n -> n % 2 == 0;
        System.out.println(isEven.test(7)); // false

        // Consumer<T>: takes a value, returns nothing -- does something with it.
        Consumer<String> shout = s -> System.out.println(s.toUpperCase() + "!");
        shout.accept("hello"); // HELLO!

        // Supplier<T>: takes nothing, produces a value on demand.
        Supplier<Double> randomValue = () -> Math.random();
        System.out.println(randomValue.get()); // some double between 0 and 1

        // --- Effectively-final capture ---
        int base = 100; // never reassigned after this line -> capturable
        Function<Integer, Integer> addBase = x -> x + base;
        System.out.println(addBase.apply(5)); // 105

        // The line below would NOT compile if uncommented, because
        // reassigning `base` makes it ineligible for capture:
        // base = 200;
        // Function<Integer, Integer> broken = x -> x + base; // compile error

        // Composing functional interfaces: Predicate has default methods
        // (covered later in this topic) that combine predicates declaratively.
        Predicate<Integer> isPositive = n -> n > 0;
        Predicate<Integer> isEvenAndPositive = isEven.and(isPositive);
        System.out.println(isEvenAndPositive.test(-4)); // false
        System.out.println(isEvenAndPositive.test(4));  // true
    }
}

Core Mechanics: The Streams API — map, filter, reduce, collect A Stream<T> is not a data structure — it holds no elements of its own. It is a one-time-use pipeline over a source (a Collection, an array, a range of numbers, lines of a file) that describes a sequence of operations to apply to that source's elements, without actually running any of them until told to. This "describe now, run later" design is called laziness, and it is the single most important thing to understand about streams, because it explains almost every surprising behavior beginners run into.

Stream operations split into two categories. Intermediate operations — map(), filter(), sorted(), distinct(), limit() — each return a new Stream, and none of them actually touch a single element when called. They just record "when this pipeline eventually runs, do this step." Terminal operations — forEach(), collect(), reduce(), count(), findFirst() — are the ones that actually trigger execution, pulling elements through every intermediate step one at a time, and after a terminal operation runs, the stream is "spent": calling any method on it again throws IllegalStateException. A stream pipeline built but never given a terminal operation does nothing at all — not an error, not a warning, just silently nothing, which is a common source of confusion for developers used to languages where each list operation runs immediately.

map(Function<T,R>) transforms each element into something else, one-to-one — Stream<Employee> to Stream<String> via .map(Employee::getName). filter(Predicate<T>) keeps only elements matching a condition, without transforming them. The two compose freely because each returns a Stream, which is why pipelines read left to right as a sequence of transformations: .filter(e -> e.getSalary() > 100000).map(Employee::getName) first narrows the set, then transforms what's left — and because of laziness, that is also the actual order of work per element: each employee is checked against the filter and, only if it passes, immediately mapped, rather than the whole collection being filtered into an intermediate list and then separately mapped.

reduce() combines all elements into a single result by repeatedly applying a BinaryOperator<T> — stream.reduce(0, (a, b) -> a + b) sums a stream of integers, starting from the identity value 0. collect() is more general: it takes a Collector, and the Collectors utility class ships implementations for the common cases — Collectors.toList(), Collectors.toSet(), Collectors.joining(", ") for strings, and Collectors.groupingBy(Employee::getDepartment) for building a Map<Department, List<Employee>> in a single call, something that used to take a hand-written loop with a HashMap.computeIfAbsent() call inside it.

A critical distinction that separates confident stream users from everyone else: streams can be sequential or parallel, and .parallelStream() or .stream().parallel() switches a pipeline to run across multiple threads using the JVM's common fork/join pool — but parallel streams only pay off for large datasets with genuinely CPU-heavy per-element work, and they introduce real hazards: a reduce() or a Collector that is not associative and stateless gives wrong, non-deterministic answers under parallel execution, and most everyday pipelines over a few hundred elements run slower in parallel because the overhead of splitting work and coordinating threads dwarfs the saved computation. Reach for .parallel() only after measuring that a specific, large, CPU-bound pipeline is actually a bottleneck — not as a default habit.

Streams are also not reusable: a reference to a Stream describes one pipeline, consumed once by its terminal operation, and a second call to .stream() on the same source collection is required to run the pipeline again. This is different from a Collection, which you can iterate as many times as you like — and forgetting it is the single most common IllegalStateException: stream has already been operated upon or closed bug newcomers hit.

import java.util.*;
import java.util.stream.*;

public class StreamsMapFilterReduceCollect {
    record Employee(String name, String department, double salary) {}

    public static void main(String[] args) {
        List<Employee> employees = List.of(
            new Employee("Asha", "Engineering", 95000),
            new Employee("Ben", "Engineering", 142000),
            new Employee("Chen", "Sales", 118000),
            new Employee("Dana", "Sales", 88000)
        );

        // --- map + filter + collect ---
        // Names of employees earning over 100k, as a List<String>.
        List<String> highEarners = employees.stream()
            .filter(e -> e.salary() > 100000)   // narrow first
            .map(Employee::name)                 // then transform
            .collect(Collectors.toList());
        System.out.println(highEarners); // [Ben, Chen]

        // --- reduce ---
        // Total payroll, folding every salary into a running sum.
        double totalPayroll = employees.stream()
            .map(Employee::salary)
            .reduce(0.0, Double::sum); // identity 0.0, combining function Double::sum
        System.out.println(totalPayroll); // 443000.0

        // --- groupingBy: a collector that replaces a hand-written HashMap loop ---
        Map<String, List<Employee>> byDepartment = employees.stream()
            .collect(Collectors.groupingBy(Employee::department));
        System.out.println(byDepartment.keySet()); // [Engineering, Sales]

        // --- a fuller pipeline: average salary per department ---
        Map<String, Double> avgSalaryByDept = employees.stream()
            .collect(Collectors.groupingBy(
                Employee::department,
                Collectors.averagingDouble(Employee::salary)
            ));
        System.out.println(avgSalaryByDept); // {Engineering=118500.0, Sales=103000.0}

        // --- laziness demonstrated ---
        Stream<Employee> pipeline = employees.stream()
            .filter(e -> {
                System.out.println("checking " + e.name()); // nothing prints yet
                return e.salary() > 100000;
            });
        System.out.println("pipeline built, nothing has run yet");
        pipeline.forEach(e -> System.out.println("matched: " + e.name())); // NOW it runs

        // --- a spent stream throws if reused ---
        try {
            pipeline.count(); // already consumed by forEach above
        } catch (IllegalStateException ex) {
            System.out.println("caught: " + ex.getMessage());
        }
    }
}