Java Lambdas & Functional Interfaces | Comparator Interface

Java was originally designed as a strict Object-Oriented Programming (OOP) language where everything revolves around objects. However, as software development evolved, the need to pass behaviors (logic) directly as arguments became critical. This chapter explores the paradigm shift from strict OOP to functional programming in Java, detailing the evolution from traditional interfaces to anonymous inner classes, and finally to modern Lambda Expressions and Functional Interfaces.

1. The Paradigm Shift: Objects vs. Behaviors in Java

In classical Java, the object is the primary citizen. Every variable, method, and behavior must be encapsulated within a class.

Because of this design, behaviors (methods) are treated as second-class citizens. You cannot define or pass a method independently; it must always be wrapped inside an object.

The Traditional OOP Workflow

To execute a simple piece of logic (a behavior) in traditional Java, you must follow a highly structured, verbose path:

While this model works exceptionally well for structuring large enterprise applications, it becomes highly inefficient and verbose when you only need to pass a single piece of execution logic to another method.

2. The Chef and the Recipe Analogy

To understand why passing behaviors directly is highly desirable, consider a real-world analogy involving a chef and a customer.

Real-Life Analogy

Imagine you are a customer visiting a restaurant, and there is a highly skilled Chef who has a general cook() method.

You want the Chef to prepare a specific dish—Pasta—according to your own custom, highly specific Recipe (which represents a set of instructions, or behavior).

• Strict OOP Approach: You cannot hand the recipe directly to the Chef. Instead, you must hire a third Person (Object), teach them the recipe, and then send that Person to the Chef. The Chef must then ask the Person to read the recipe. This is an unnecessary, over-engineered step.
• Functional Approach: You hand the recipe (the raw behavior/instructions) directly to the Chef's cook() method. The Chef executes the instructions immediately without needing an intermediary person.

The Programming Equivalent

In Java, methods can only accept variables as arguments. These variables can be:

1. Primitives: int, float, double, char, etc.
2. Reference Variables: Objects (e.g., Student s1, String str).

Prior to Java 8, you could not pass a method/behavior directly as an argument. You had to wrap the behavior inside an object and pass that object instead.

3. The Sorting Problem: Comparable vs. Comparator

To see this limitation in action, let us look at a common programming task: sorting a list of custom objects.

The Domain Model: Student Class

Consider a simple Student class containing a name, roll number, and marks:

class Student {
    String name;
    int rollNumber;
    int marks;

    public Student(String name, int rollNumber, int marks) {
        this.name = name;
        this.rollNumber = rollNumber;
        this.marks = marks;
    }
}

If we create a list of these students and attempt to sort them using Collections.sort(), the compiler will throw an error:

List<Student> list = new ArrayList<>();
list.add(new Student("Aditya", 101, 85));
list.add(new Student("Rohit", 102, 89));

Collections.sort(list); // Compilation Error!

Why does this fail? Java does not know how to compare two Student objects. Unlike integers or strings, which have a natural, obvious ordering, a Student can be sorted by name, rollNumber, or marks.

Two Solutions: Comparable vs. Comparator

If a class implements Comparable, it is locked into one sorting strategy (e.g., always sorting by marks). If different actors (e.g., a Teacher sorting by marks, an Admin sorting by names, a Registrar sorting by roll numbers) require different sorting strategies, Comparable is insufficient. We must use Comparator.

4. Step-by-Step Evolution: Traditional Comparators

To implement multiple sorting strategies using the traditional OOP approach, we must create separate classes for each strategy, implementing the Comparator interface.

Step 1: Define the Comparator Classes

import java.util.Comparator;

// Strategy 1: Sort by Name
class SortByName implements Comparator<Student> {
    @Override
    public int compare(Student s1, Student s2) {
        return s1.name.compareTo(s2.name);
    }
}

// Strategy 2: Sort by Marks
class SortByMarks implements Comparator<Student> {
    @Override
    public int compare(Student s1, Student s2) {
        return s1.marks - s2.marks; // Ascending order
    }
}

// Strategy 3: Sort by Roll Number
class SortByRollNumber implements Comparator<Student> {
    @Override
    public int compare(Student s1, Student s2) {
        return s1.rollNumber - s2.rollNumber;
    }
}

Step 2: Instantiate and Pass the Objects

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<Student> list = new ArrayList<>();
        list.add(new Student("Aditya", 1001, 85));
        list.add(new Student("Rohit", 1002, 89));
        list.add(new Student("Rohan", 1003, 93));
        list.add(new Student("Sounu", 1004, 98));

        // Sort by Name using C1
        Comparator<Student> c1 = new SortByName();
        Collections.sort(list, c1);

        // Sort by Marks using C2
        Comparator<Student> c2 = new SortByMarks();
        Collections.sort(list, c2);
    }
}

The Problem with this Approach

This code is incredibly verbose. To pass a single line of actual logic (s1.marks - s2.marks), we had to:

1. Define a brand-new class (SortByMarks).
2. Implement the Comparator interface.
3. Override the compare method.
4. Instantiate the class to create an object (c2).
5. Pass that object to Collections.sort().

5. Step-by-Step Evolution: Anonymous Inner Classes

To reduce the overhead of creating multiple physical classes, Java introduced Anonymous Inner Classes. This allows us to declare and instantiate a class simultaneously at the location where it is needed.

Implementing Anonymous Inner Classes

Collections.sort(list, new Comparator<Student>() {
    @Override
    public int compare(Student s1, Student s2) {
        return s1.name.compareTo(s2.name);
    }
});

Why This is Still Imperfect

While this eliminates the need to create separate named files or classes, the code remains highly verbose and cluttered with boilerplate:

new Comparator<Student>() {
    @Override
    public int compare(Student s1, Student s2) {
        ...
    }
}

Conceptually, we are still wrapping our behavior inside a temporary, nameless class container. The only line we actually care about is:

return s1.name.compareTo(s2.name);

6. The Modern Solution: Functional Interfaces

To enable true functional programming, Java 8 introduced Functional Interfaces.

Definition

A Functional Interface is an interface that contains exactly one abstract method.

• It can contain any number of static or default methods (since these are already defined/implemented).
• It acts as the target type for Lambda Expressions.

Examples of Functional Interfaces in Java

1. java.lang.Runnable
   JAVA

   Copy

   @FunctionalInterface
   public interface Runnable {
       public abstract void run();
   }
   

2. java.util.Comparator
   JAVA

   Copy

   @FunctionalInterface
   public interface Comparator<T> {
       int compare(T o1, T o2);
       // Other default/static methods may exist
   }
   

The @FunctionalInterface Annotation

This annotation is optional but highly recommended. It instructs the compiler to enforce the single abstract method rule. If someone accidentally adds a second abstract method to the interface, the compiler will throw an error.

@FunctionalInterface
interface Demo {
    void m1(); // Single Abstract Method (SAM)
    
    // Adding another abstract method here would cause a compilation error!
}

7. The Modern Solution: Lambda Expressions

A Lambda Expression is an anonymous (nameless) method that allows you to treat actions/behaviors as values. It provides a highly condensed syntax to implement the single abstract method of a functional interface.

The Anatomy of a Lambda Expression

A lambda expression consists of three distinct parts:

Transforming Anonymous Classes to Lambdas

Let's look at the transformation of the compare method:

1. The Traditional Anonymous Class:

new Comparator<Student>() {
    @Override
    public int compare(Student s1, Student s2) {
        return s1.marks - s2.marks;
    }
}

2. The Lambda Equivalent:

(s1, s2) -> s1.marks - s2.marks

Complete Modern Implementation

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class DemoLambda {
    public static void main(String[] args) {
        List<Student> list = new ArrayList<>();
        list.add(new Student("Aditya", 1001, 85));
        list.add(new Student("Rohit", 1002, 89));
        list.add(new Student("Rohan", 1003, 93));
        list.add(new Student("Sounu", 1004, 98));

        // Sorting by Marks using a clean Lambda Expression
        Collections.sort(list, (s1, s2) -> s1.marks - s2.marks);

        // Printing the sorted list
        for (Student s : list) {
            System.out.println(s.name + ", " + s.rollNumber + ", " + s.marks);
        }
    }
}

8. Lambda Syntax Variations & Rules

Depending on the number of parameters and the complexity of the logic, the syntax of a lambda expression can change.

Multi-Line Lambda Example

If your logic requires multiple statements, you must wrap the body in curly braces {} and use an explicit return statement:

Collections.sort(list, (s1, s2) -> {
    int diff = s1.marks - s2.marks;
    // Additional logging or logic can go here
    return diff;
});

Warning: If you use curly braces {} in a lambda body, you must write an explicit return statement if the functional interface's method expects a return value. Omitting return inside braces will cause a compilation error.

9. How Java Infers Lambdas: Target Typing & Context

A common question arises: How does Java know the types of the parameters in a lambda expression without explicit declarations?

For example, in this expression:

(s1, s2) -> s1.marks - s2.marks

Java automatically infers that s1 and s2 are of type Student. This mechanism is known as Target Typing.

The Inference Pipeline

Because of this deep contextual analysis, Java provides complete compile-time safety while allowing you to write clean, concise code without explicit type declarations.

10. Creating Custom Functional Interfaces

You can easily design your own functional interfaces to pass custom behaviors around your application.

Step 1: Define the Interface

Use the @FunctionalInterface annotation to protect your interface from accidental modifications.

@FunctionalInterface
interface Calculator {
    int operate(int a, int b);
}

Step 2: Implement and Use via Lambdas

public class CustomInterfaceDemo {
    public static void main(String[] args) {
        // Define addition behavior
        Calculator addition = (a, b) -> a + b;
        
        // Define multiplication behavior
        Calculator multiplication = (a, b) -> a * b;

        // Execute behaviors
        System.out.println("Addition: " + addition.operate(10, 5));         // Output: 15
        System.out.println("Multiplication: " + multiplication.operate(10, 5)); // Output: 50
    }
}

11. Summary and Key Takeaways

• Paradigm Shift: Java 8 introduced functional programming concepts to complement its robust OOP foundation, reducing boilerplate and making behaviors first-class citizens.
• Functional Interfaces: These are interfaces with exactly one abstract method (SAM). They serve as the foundation and target type for all lambda expressions.
• Lambda Expressions: A concise, anonymous syntax (parameters) -> body used to implement functional interfaces directly inline.
• Target Typing: Java's compiler dynamically infers parameter types and return types of lambda expressions based on the surrounding context (the target type).
• Comparable vs. Comparator: Use Comparable for a class's default, natural ordering. Use Comparator with lambdas to define multiple, dynamic sorting strategies externally.
• Syntax Flexibility: Parentheses are optional for single parameters, and curly braces/return statements are only required for multi-line lambda bodies.
• Compile-Time Safety: The @FunctionalInterface annotation ensures that an interface remains a valid functional interface, preventing accidental additions of other abstract methods.