Functional & Marker Interfaces

## What problem this solves Before Java 8, to pass a small piece of behavior to a method (for example, telling `Collections.sort` how to order elements), you had to write a whole anonymous class. That was verbose. Java 8 introduced **lambda expressions** — a compact syntax for an anonymous function — and **method references**. But Java is statically typed: every value must have a type. A lambda has no class of its own, so the language needs to know *what interface* the lambda is implementing. That target type is a **functional interface**. ## Definition An **interface** is a contract: a named set of methods a class promises to provide. An **abstract method** is a method with no body — just a signature — that an implementer must fill in. A **functional interface** is simply an interface that has **exactly one abstract method**. Because there is exactly one method to supply, the compiler can take a lambda (a bare method body) and know it belongs to that single method. The jargon term for this is a **SAM type** (Single Abstract Method). ```java interface Greeter { // functional: one abstract method String greet(String name); } Greeter g = name -> "Hi " + name; // lambda implements greet ``` ## What counts as "the one abstract method" The rule is more precise than "one method total." These do **not** count against the single-abstract-method requirement: - **default methods** — methods in an interface that already have a body (introduced in Java 8). - **static methods** — methods called on the interface itself, not on an instance. - **private methods** — internal helpers (Java 9+). - **public methods that override `java.lang.Object`** — for example, an interface may re-declare `boolean equals(Object)` or `String toString()`. Since every object already inherits these from `Object`, they are not a new abstract method to implement. So an interface can have many default/static methods and still be a valid functional interface, as long as **exactly one** truly-abstract, non-Object method remains. `Comparator<T>` is the classic example: its single abstract method is `compare(T, T)`, yet it has many default and static helpers like `reversed()` and `thenComparing()`. ## @FunctionalInterface `@FunctionalInterface` is an **annotation** — metadata you place above the interface. It is **optional**: an interface is functional based on its shape, not on the annotation. Its job is twofold: 1. **Documentation** — it signals to readers "this is meant to be used as a lambda target." 2. **Compile-time enforcement** — if you add a second abstract method later, the build fails with an error. Without the annotation, adding a second abstract method silently and quietly breaks every lambda that targeted it, but only at the call sites, with a confusing message. With the annotation, the error points right at the interface. ```java @FunctionalInterface interface Transformer { String apply(String s); // adding 'int count();' here would now fail to compile } ``` ## The JDK's standard functional interfaces The package `java.util.function` provides ready-made functional interfaces so you rarely need to invent your own: `Function<T,R>` (takes a T, returns an R), `Predicate<T>` (takes a T, returns boolean), `Supplier<T>` (takes nothing, returns a T), `Consumer<T>` (takes a T, returns nothing), `BiFunction`, `UnaryOperator`, and primitive-specialized variants like `IntPredicate`. Older single-method interfaces — `Runnable`, `Callable`, `Comparator` — are also functional and work with lambdas. ## Why it matters Functional interfaces are the bridge that makes lambdas, method references, and the Streams API possible. Every `stream.map(x -> ...)`, every `list.forEach(System.out::println)`, every `Comparator.comparing(...)` relies on a functional interface as the target type.