Java Method Parameters: By Value, Reference, and Varargs

Java method parameters follow a single rule: arguments are always passed by value. That rule is easy to state but easy to misinterpret when the parameter is a reference type. This article explains what pass-by-value actually means for primitives and objects, how varargs work, and where parameter design affects maintainability and performance.

What Pass-by-Value Means for Primitives

When you pass a primitive value like int, double, or boolean to a method, the method receives a copy of the value. Changes made to the parameter inside the method have no effect on the original variable.

public static void increment(int number) {
    number++;
}

public static void main(String[] args) {
    int count = 5;
    increment(count);
    System.out.println(count); // still 5
}

The count variable remains 5 because increment works on a copy. This is the fundamental behavior of pass-by-value for primitives. There is no way to change the caller's primitive variable through a method parameter in Java, except by returning a new value and assigning it.

How Reference Types Behave as Parameters

For reference types, the value being copied is the reference (a pointer-like handle) to the object, not the object itself. This means the method can modify the object's state, but it cannot reassign the caller's reference to a different object.

public static void addItem(List<String> list, String item) {
    list.add(item); // modifies the object the reference points to
}

public static void reassign(List<String> list) {
    list = new ArrayList<>(); // only affects the local copy of the reference
}

public static void main(String[] args) {
    List<String> names = new ArrayList<>();
    addItem(names, "Alice");
    System.out.println(names.size()); // 1
    reassign(names);
    System.out.println(names.size()); // still 1
}

The addItem method changes the list's contents because the reference copy points to the same ArrayList object. The reassign method creates a new ArrayList and assigns it to the local parameter, but the caller's names reference still points to the original list. This distinction is critical when designing methods that accept collections or mutable objects.

Using Varargs for Variable-Length Arguments

Java supports variable-length argument lists through varargs syntax. A varargs parameter is declared with an ellipsis (...) after the type, and it behaves as an array inside the method.

public static int sum(int... numbers) {
    int total = 0;
    for (int number : numbers) {
        total += number;
    }
    return total;
}

public static void main(String[] args) {
    System.out.println(sum(1, 2, 3));      // 6
    System.out.println(sum(10, 20));       // 30
    System.out.println(sum());               // 0
}

The varargs parameter must be the last parameter in the method signature. You can pass zero or more arguments, or you can pass an array directly. This is useful for methods like String.format or logging utilities where the number of arguments varies.

Parameter Order and Naming Conventions

Method parameters are positional, so order matters. A well-designed parameter order improves readability and reduces the chance of passing arguments in the wrong order. For example, a method that copies a range from one array to another should take the source first, then the destination, then the indices, matching the mental model of the operation.

Naming also matters. Use descriptive names that convey the role of each parameter. Avoid single-letter names except in mathematical contexts where they are conventional. For example, int index is clearer than int i. When a method takes multiple parameters of the same type, the names become the only way to distinguish them at the call site.

Common Mistakes with Method Parameters

One common mistake is assuming that passing a reference type allows you to reassign the caller's variable. As shown earlier, that is not the case. Another mistake is to modify a parameter that is used later in the same method, which can lead to subtle bugs. For example, if you sort a list parameter and then use the original order elsewhere, you may not realize the list has been changed.

A third mistake is to overuse varargs when a fixed number of parameters is clearer. Varargs hides the number of arguments and can make the method's contract vague. For instance, a method that expects exactly two coordinates should take two int parameters, not int... coordinates, because the latter allows invalid call counts.

Performance and Maintainability Considerations

Passing primitives by value has no performance cost beyond copying a small value. Passing references copies the reference, which is also cheap. The real cost appears when you copy the underlying object manually, such as using clone() or creating a defensive copy. Defensive copies are sometimes necessary to protect internal state, but they add allocation and copying overhead. Use them only when the method must not be affected by later changes to the caller's object.

Varargs creates an array for each invocation, which adds a small allocation cost. For hot paths, consider overloading with fixed arity methods instead. For maintainability, prefer a clear, minimal set of parameters. Methods with many parameters are hard to read and easy to call incorrectly. If a method needs more than three or four parameters, consider grouping related ones into a parameter object or using a builder pattern.

Reference Parameters and Nullability

Java does not have a built-in way to express whether a parameter can be null. This is a source of many NullPointerException failures. You can use Objects.requireNonNull to fail fast with a clear message.

public static void process(String value) {
    Objects.requireNonNull(value, "value must not be null");
    // rest of the method
}

This explicit check makes the contract visible and avoids debugging a null reference later. For APIs where null is a valid input, document that clearly and handle it deliberately. The absence of nullability annotations in standard Java means the developer must be disciplined about documenting and checking parameter constraints.

Choosing Between Overloading and Varargs

When a method can accept a varying number of arguments, you have two main options: overload the method for each arity, or use varargs. Overloading gives you compile-time type safety and avoids array allocation, but it requires you to write multiple method bodies. Varargs is concise and flexible, but it can accept zero arguments, which may not be meaningful for your use case.

For example, a log method that accepts a message and optional tags could use varargs. But if the first argument is always required and the rest are optional, you can use a fixed parameter followed by a varargs parameter. Overloading is better when the number of arguments is small and fixed, such as a point method that always takes two coordinates. Varargs is better when the number is genuinely variable and the method treats all arguments uniformly.

Consider the caller experience. Varargs allows calls like sum(1, 2, 3) and sum(), which may be convenient. Overloading restricts calls to the defined arities, which can prevent accidental misuse. The choice depends on how strict you want the method contract to be.