Method references

For this lesson, we'll focus on the four forms you need for interviews: static, bound instance, unbound instance, and constructor references, including array constructors like int[]::new. We'll also cover how each form maps to a target method signature, when it reads better than a lambda, and the two traps I see in code reviews: overload ambiguity and eager evaluation of a bound receiver.

01Picture it first: address labels for existing work

A method reference is like putting an address label on work that already exists. You are not writing the work again; you are saying "when the functional interface asks, call that method". The label is only valid if the target slot has the right shape.

The four labels differ mainly in where the receiver comes from. Sometimes the receiver is already fixed (logger::info), and sometimes the receiver becomes the first parameter (String::trim).

Fig. 1

The four method-reference forms show static, bound instance, unbound instance and constructor references alongside the equivalent lambda shape and where the receiver comes from

Keep that receiver question in your head. Most method-reference confusion is really receiver confusion.

02Method references under the hood: the four forms

Function<String, Integer> parse = Integer::parseInt;
Consumer<String> print = System.out::println;
ToIntFunction<String> length = String::length;
Supplier<ArrayList<Order>> newList = ArrayList::new;
IntFunction<int[]> newIntArray = int[]::new;

Here is the mapping I use on a whiteboard.

A static reference is the easiest: all functional-interface arguments become method arguments. A bound instance reference stores the receiver first, then the functional-interface arguments become the method arguments. An unbound instance reference is the one to slow down for: the first functional-interface argument becomes the receiver.

Constructor references follow constructor signatures. If new OrderDto(Order) exists, then OrderDto::new fits Function<Order, OrderDto>. If new Money(long, Currency) exists, then Money::new fits BiFunction<Long, Currency, Money> with boxing on Long; for a primitive-heavy path you would usually write a domain interface like MoneyFactory { Money create(long cents, Currency currency); }.

Signature matching, not name matching

A method reference does not match by method name alone. It matches the target interface's single abstract method after overload resolution.

record Order(String id, long totalCents) {}
record OrderDto(String id, long totalCents) {
    OrderDto(Order order) {
        this(order.id(), order.totalCents());
    }
}

Function<Order, OrderDto> toDto = OrderDto::new;
Predicate<String> blank = String::isBlank;
UnaryOperator<String> trim = String::trim;
BiPredicate<String, String> startsWith = String::startsWith;

String::startsWith looks like one method, but as an unbound reference it needs two inputs for BiPredicate<String, String>: first the receiver string, then the prefix. That maps to (text, prefix) -> text.startsWith(prefix).

Notice three things:

• The target return type matters. String::length fits ToIntFunction<String> cleanly and Function<String, Integer> with boxing. It does not fit Predicate<String>.
• The target arity matters. System.out::println as a bound reference can fit Consumer<String>, but not BiConsumer<PrintStream, String> because the receiver is already fixed.
• Constructors are overloaded too. ArrayList::new can fit Supplier<ArrayList<String>> for the no-arg constructor or IntFunction<ArrayList<String>> for the initial-capacity constructor.

Bound versus unbound, said slowly

The quickest way to decide between bound and unbound is to ask, "do I already have the object that will receive the call?" If yes, the receiver is bound. If no, the receiver must arrive as one of the functional-interface arguments.

PrintStream out = System.out;
Consumer<String> bound = out::println;          // text -> out.println(text)

ToLongFunction<Order> unbound = Order::totalCents; // order -> order.totalCents()
Supplier<Long> alsoBound = order::totalCents;       // () -> order.totalCents()

The method name is the same in the last two lines, but the shape is not. Order::totalCents still needs an Order, so it fits ToLongFunction<Order>. order::totalCents already has the Order, so it fits Supplier<Long> or LongSupplier depending on whether you want boxing.

This is also why ClassName::instanceMethod feels odd at first. It is not static dispatch. It is a compact way to say "take the first argument, use it as the receiver, and pass the remaining arguments to the instance method".

03When a reference is clearer, and when it is not

orders.stream()
        .filter(Order::isPaid)
        .map(Order::customerEmail)
        .forEach(mailer::sendReceipt);

orders.stream()
        .filter(order -> order.totalCents() >= minimumCents)
        .map(order -> normalize(order.customerEmail()))
        .forEach(email -> mailer.sendReceipt(email));

In the first pipeline, method references read like a list of operations: is paid, get email, send receipt. The names carry the whole meaning, so the syntax gets out of the way.

In the second pipeline, I would keep the lambdas. The first captures a threshold and tells you which argument is compared. The second wraps a call. The third is equivalent to mailer::sendReceipt, but the named email parameter may be clearer if the type is not obvious nearby.

Here is my default: use a method reference when it is exactly the method you would have named anyway. Use a lambda when you transform arguments, add constants, reorder parameters, handle nulls, branch, or need a parameter name to make the code readable.

Many candidates repeat "prefer method references" as if it is a law. Effective Java says to prefer them when they are shorter and clearer. If the lambda explains intent better, keep the lambda.

04Real world: eager bound receivers

Bound instance references evaluate the receiver immediately. That is true even though the method call itself happens later.

class Scheduler {
    void everyMinute(Runnable task) { /* store task and run it later */ }
}

Metrics metrics = null;
Scheduler scheduler = new Scheduler();

scheduler.everyMinute(metrics::flush);      // NullPointerException now
scheduler.everyMinute(() -> metrics.flush()); // accepted now, throws when run

Fig. 2

A bound reference metrics::flush checks the metrics receiver during task creation and throws immediately when null, while a lambda stores code and reads metrics later when run

This also affects mutable static fields. System.out::println captures the current PrintStream. x -> System.out.println(x) reads System.out each time it runs. Most code should not depend on that, but it is a great interview detail because it proves you understand bound references.

05Advanced: overloads, ambiguity and constructors

Overloads are where method references stop feeling magical. Because the reference has no type until the target is known, two possible targets can leave the compiler unable to choose.

void handle(Function<String, Integer> parser) {}
void handle(ToIntFunction<String> parser) {}

// handle(Integer::parseInt);        // ambiguous
handle((ToIntFunction<String>) Integer::parseInt);

void log(Consumer<String> writer) {}
void log(Predicate<String> checker) {}

// log(String::isBlank);             // picks Predicate if available alone, ambiguous with another boolean target
log((Predicate<String>) String::isBlank);

The clean fixes are boring and reliable: assign the reference to a typed variable, cast it at the call site, or avoid overloading methods on functional interfaces with similar shapes. As an API designer, I avoid overload sets like handle(Function<...>) and handle(ToIntFunction<...>) unless callers truly benefit.

There is a team-level lesson here too. If a public API accepts callbacks, give each overload a different name when the callback shapes are close. handleObject and handleInt look less elegant than one overloaded handle, but they save every caller from sprinkling casts around lambdas and method references. Readability at the call site wins.

Constructor references have the same overload story:

import java.util.*;
import java.util.function.*;

Supplier<ArrayList<String>> empty = ArrayList::new;
IntFunction<ArrayList<String>> sized = ArrayList::new;
IntFunction<int[]> ints = int[]::new;

String[] names = List.of("a", "b").toArray(String[]::new);

String[]::new is the common collection-to-array pattern because Collection.toArray(IntFunction<T[]>) asks for a function from size to array. For primitive arrays, int[]::new fits IntFunction<int[]>, which is int -> int[].

There is one more readability edge case: generic methods. A method reference can sometimes express a generic target that a lambda cannot, because lambda expressions cannot declare their own type parameters. You rarely need that in application code, but it is why "method references are only shorter lambdas" is not quite complete.

06How to say it in the interview

When I ask this, I'm listening for the receiver story. A good answer names all four forms, maps at least one unbound reference correctly, and mentions the eager-null behavior of bound references without being prompted.

method reference = lambda that delegates
target functional interface still supplies the type

static:       Integer::parseInt  == s -> Integer.parseInt(s)
bound:       out::println       == x -> out.println(x)
unbound:     String::length     == s -> s.length()
constructor: ArrayList::new     == () -> new ArrayList<>()
array ctor:  int[]::new         == n -> new int[n]

unbound receiver = first parameter
bound receiver evaluated immediately
overload ambiguity: type variable | cast | avoid overloads
clarity rule: reference when name says it all, lambda when logic changes