Introduction

Java does not pass methods as standalone values in the same way some functional languages do. What it does pass are objects that represent behavior, most commonly lambdas, method references, or instances of functional interfaces. Once you understand that distinction, "passing a method as a parameter" becomes a normal part of Java API design.

Use standard functional interfaces when possible

Since Java 8, the most common approach is to accept a functional interface from java.util.function. For example, if your code needs "something that takes a string and returns a string," Function<String, String> is a natural fit.

1import java.util.function.Function;
2
3public class StringTransformer {
4    public static String applyTwice(String input, Function<String, String> transform) {
5        return transform.apply(transform.apply(input));
6    }
7
8    public static void main(String[] args) {
9        String result = applyTwice("  hello  ", text -> text.trim().toUpperCase());
10        System.out.println(result);
11    }
12}

The method applyTwice is not receiving a raw method pointer. It is receiving an object whose single abstract method can be invoked. That is what makes lambdas and method references work in Java.

Method references are the closest thing to passing a method

If you already have an existing method whose signature matches the functional interface, you can pass it with a method reference. This is usually the cleanest syntax.

1import java.util.Arrays;
2import java.util.List;
3import java.util.function.Consumer;
4
5public class MethodReferenceExample {
6    public static void forEachValue(List<String> values, Consumer<String> action) {
7        for (String value : values) {
8            action.accept(value);
9        }
10    }
11
12    public static void printValue(String value) {
13        System.out.println(value);
14    }
15
16    public static void main(String[] args) {
17        List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
18        forEachValue(names, MethodReferenceExample::printValue);
19    }
20}

MethodReferenceExample::printValue is the Java syntax that most closely resembles "pass this method." Under the hood, Java still adapts it to the target functional interface type, in this case Consumer<String>.

Create a custom interface for domain-specific behavior

Standard interfaces cover many common shapes, but sometimes a named interface makes the code clearer. That is useful when the behavior has business meaning beyond input and output types.

1@FunctionalInterface
2interface PriceRule {
3    double apply(double basePrice);
4}
5
6public class Checkout {
7    public static double calculate(double price, PriceRule rule) {
8        return rule.apply(price);
9    }
10
11    public static double addTax(double price) {
12        return price * 1.13;
13    }
14
15    public static void main(String[] args) {
16        double taxed = calculate(100.0, Checkout::addTax);
17        double discounted = calculate(100.0, p -> p * 0.9);
18
19        System.out.println(taxed);
20        System.out.println(discounted);
21    }
22}

The @FunctionalInterface annotation is optional but helpful. It tells both readers and the compiler that the interface is intended to have exactly one abstract method.

Anonymous classes still matter in older code

Before Java 8, the usual pattern was to pass an anonymous class. You still see this in older codebases and some callback-heavy APIs.

1interface Task {
2    void run();
3}
4
5public class LegacyStyle {
6    public static void execute(Task task) {
7        task.run();
8    }
9
10    public static void main(String[] args) {
11        execute(new Task() {
12            @Override
13            public void run() {
14                System.out.println("Running legacy callback");
15            }
16        });
17    }
18}

This is more verbose than a lambda, but it follows the same core rule: Java passes an object that implements a known interface, not a free-floating method.

Choose the right interface shape

The main design question is usually not "how do I pass a method?" but "what behavior does this API need?" If the caller only consumes a value, Consumer<T> is a good fit. If it returns a value, Function<T, R> or Supplier<T> may fit better. If it takes two inputs, BiFunction<T, U, R> or BiConsumer<T, U> may be more natural.

Choosing the right type makes the call site readable and prevents awkward wrappers later.

Common Pitfalls

The biggest pitfall is thinking Java methods are first-class values. They are not. Java supports behavior passing through functional interfaces and object adaptation.

Another common mistake is picking the wrong functional interface. For example, using Runnable when the operation actually needs input data forces you to capture external state and makes the code harder to test.

Developers also run into confusion with overloaded methods. A method reference must match the target functional interface clearly, or the compiler may reject it as ambiguous.

Finally, avoid creating a custom interface when a standard one such as Function, Predicate, or Consumer already expresses the intent well.

Summary

• Java does not pass bare methods directly; it passes behavior through functional interfaces.
• Lambdas and method references are the modern way to supply that behavior.
• Method references are ideal when an existing method already matches the required signature.
• Custom functional interfaces are useful when the behavior has domain meaning.
• Anonymous classes are the older equivalent and still appear in pre-Java 8 code.