Functional Interfaces & Method References

// An anonymous inner class generates a separate class file at COMPILE time:
// Outer$1.class
Runnable r1 = new Runnable() { public void run() { System.out.println("anon"); } };

// A lambda instead uses invokedynamic, with the actual implementing class
// generated lazily at RUNTIME on first use, via LambdaMetafactory
Runnable r2 = () -> System.out.println("lambda");

Common follow-ups: Why did the JDK designers choose invokedynamic and runtime class generation over simply compiling lambdas the same way as anonymous inner classes?;What performance implications does this dynamic class generation have for the very first invocation of a given lambda expression versus subsequent invocations?

Map<String, Integer> ages = Map.of("Alice", 30, "Bob", 25);

// BiConsumer used directly via Map.forEach()
ages.forEach((name, age) -> System.out.println(name + " is " + age + " years old"));

// Equivalent using an explicit BiConsumer variable
BiConsumer<String, Integer> printer = (name, age) -> System.out.println(name + ": " + age);
ages.forEach(printer);

Common follow-ups: What's the equivalent BiFunction and BiPredicate interfaces, and what scenarios call for each?;Why doesn't Consumer have an andThen()-based way to short-circuit, unlike Predicate's and()/or()?

@FunctionalInterface
interface Validator<T> {
    List<String> validate(T input);

    default Validator<T> and(Validator<T> other) {
        return input -> {
            List<String> errors = new ArrayList<>(this.validate(input));
            errors.addAll(other.validate(input));  // accumulates BOTH, doesn't short-circuit
            return errors;
        };
    }
}

Validator<String> notEmpty = s -> s.isEmpty() ? List.of("must not be empty") : List.of();
Validator<String> maxLength = s -> s.length() > 20 ? List.of("too long") : List.of();
Validator<String> combined = notEmpty.and(maxLength);
System.out.println(combined.validate(""));  // reports BOTH applicable errors if both rules fail

Common follow-ups: What's the performance trade-off of always running every validator (no short-circuiting) versus Predicate's short-circuit behavior?;How would you extend this design to also support conditional validators that only apply under certain circumstances?

// Standard Function doesn't allow this to compile directly:
// Function<String, byte[]> reader = Files::readAllBytes;  // COMPILE ERROR: IOException is checked

// Workaround: wrap the checked exception as unchecked inside the lambda
Function<String, byte[]> reader = path -> {
    try {
        return Files.readAllBytes(Path.of(path));
    } catch (IOException e) {
        throw new UncheckedIOException(e);  // wraps checked as unchecked, now compiles fine
    }
};

Common follow-ups: What is the 'sneaky throw' technique, and why is it considered controversial despite technically working?;How would defining your own checked-exception-permitting functional interface change this trade-off?

void process(Runnable r) { System.out.println("Runnable overload"); }
void process(Callable<String> c) { System.out.println("Callable overload"); }

// Ambiguous! A no-arg lambda with no return matches Runnable; compiler needs disambiguation for a mixed case
process(() -> System.out.println("hi"));  // resolves to Runnable, since it has no return value

// Explicit cast resolves genuine ambiguity when needed
process((Callable<String>) () -> { return "result"; });

Common follow-ups: What specific rules does the Java Language Specification use to rank 'most specific' among ambiguous functional interface overloads?;How does explicit lambda parameter type annotation (like (String s) -> ... instead of s -> ...) help resolve certain ambiguous inference scenarios?