Methods in Java: Parameters, Return Values, and Overloading

Executive Summary

Methods in Java have a signature (name plus parameter types) and a body, and the compiler checks every return path before it accepts the code. Java passes everything by value: primitives copy their values, and objects copy the reference, so a method can mutate an object’s state but can never reassign the caller’s variable. Overloading lets one name serve several parameter lists, resolved at compile time by the most specific match; ambiguity is a compile error, not a runtime surprise. Varargs accept any number of same-typed arguments and must come last. Design methods small and honest: guard-return early, avoid boolean flag parameters, and replace long parameter lists with a record. These habits are also the foundation of testing, because a method with clear inputs and outputs is exactly the unit your JUnit tests will call.

The Anatomy of Methods in Java

A method declaration has five parts: modifiers, a return type, a name, a parameter list, and a body. The signature, which is what the compiler compares, is only the name plus the parameter types, as the JLS class-member chapter defines.

public static double area(double radius) {
    return Math.PI * radius * radius;
}
// modifiers:      public static
// return type:    double
// name:           area
// parameter list: (double radius)
// signature:      area(double)

Callers use the name, pass arguments, and receive the answer:

double floor = area(2.0);      // 12.566...
System.out.println(area(3));   // int widens to double automatically

Method names use lowerCamelCase and should read as verbs: area, isEven, sendInvoice. If you need a sentence to explain what a name does, the problem is the method, not the name. For a shorter first look at methods alongside if statements and loops, see the Java Mini Series post on methods and control flow.

Here is one complete, copy-pasteable class using everything this article covers:

public class MiniMath {

    static int max(int a, int b) {
        return a >= b ? a : b;
    }

    static long max(long a, long b) {       // overload: same idea, wider type
        return a >= b ? a : b;
    }

    static boolean isEven(int n) {
        return n % 2 == 0;
    }

    static int sum(int... values) {         // varargs: any count
        int total = 0;
        for (int value : values) {
            total += value;
        }
        return total;
    }

    public static void main(String[] args) {
        System.out.println(max(3, 9));          // 9  (int version)
        System.out.println(max(3L, 9L));        // 9  (long version)
        System.out.println(isEven(10));        // true
        System.out.println(sum(1, 2, 3, 4));   // 10
    }
}

Two of those methods share a name with identical semantics, one accepts any number of arguments, and every one does a single job. That is the whole design philosophy of methods in one file.

Parameters: Java Is Pass-by-Value, Always

Every parameter is a copy. For primitives, the method receives a copy of the value. For objects, the method receives a copy of the reference, and that copy still points at the same object. Consequently, two things are true at once: the method can change the object’s state, and it cannot point the caller’s variable at a different object.

Wrong code first. This classic interview demo is also a real bug shape:

// WRONG: swap looks correct and does nothing
static void swap(int a, int b) {
    int temp = a;
    a = b;
    b = temp;
}
// caller:
int x = 1, y = 2;
swap(x, y);
System.out.println(x + " " + y);   // still 1 2

// RIGHT: return the new arrangement instead
static int[] swapped(int a, int b) {
    return new int[] { b, a };
}

int[] pair = swapped(1, 2);   // [2, 1]

The delta: a and b were copies, so the dance inside swap changed only the copies. Returning the result moves the change through the one channel Java gives you: the return value.

The same rule explains object behavior, and this pair of examples settles the “by reference” confusion for good:

static void rename(StringBuilder sb) {
    sb.append("-v2");            // visible to the caller: same object
}

static void replace(StringBuilder sb) {
    sb = new StringBuilder();     // invisible to the caller: only the copy moved
}

rename mutates the object both variables point at, so the caller sees the change. replace reassigns the local copy, so the caller sees nothing. The official tutorial on methods states the rule in one line: you cannot pass by reference in Java.

Return Values, void, and Guard Returns

Every non-void method must return on every path, and the compiler proves it or rejects the file. Prefer guard returns over deep nesting: handle the failing cases first, then carry the happy path un-indented.

static String grade(int score) {
    if (score < 0 || score > 100) {
        throw new IllegalArgumentException("score out of range: " + score);
    }
    if (score >= 90) return "A";
    if (score >= 80) return "B";
    return "C or below";
}

void methods return nothing; a bare return; exits early. Exceptions like the one above get their full treatment in Part 3’s exception articles, where throwing becomes a design tool rather than a reflex.

Varargs: A Variable Number of Arguments

When a method should accept any number of same-typed values, declare varargs with three dots. The parameter becomes an array inside the method, so loops and length work as usual. One rule matters: varargs must be the last parameter, as the varargs tutorial shows.

static int sum(int first, int... rest) {
    int total = first;
    for (int value : rest) {
        total += value;
    }
    return total;
}

sum(10);               // 10
sum(10, 20);           // 30
sum(10, 20, 30, 40);   // 100

You have already used this shape without knowing its name: String.format(String, Object…) and printf both take varargs.

Overloading: One Name, Several Parameter Lists

Overloading gives one method name several parameter lists. The compiler resolves calls by the arguments’ static types at compile time, choosing the most specific match. Because return type is not part of the signature, two methods differing only by return type do not compile.

Change	Example	Result
Different parameter count	sum(int) and sum(int, int)	Valid overloads
Different parameter types	sum(int, int) and sum(double, double)	Valid overloads
Different parameter order	print(int, String) and print(String, int)	Valid overloads
Return type only	int sum() and long sum()	Compile error
Ambiguous call	print(1, 2) with (int, long) and (long, int)	Compile error

static void print(int a, long b) { System.out.println("int, long"); }
static void print(long a, int b) { System.out.println("long, int"); }

print(1, 2L);   // int, long
print(1L, 2);   // long, int
// print(1, 2); // compile error: reference to print is ambiguous

Overload only with identical semantics: max(int, int) and max(double, double) compute the same idea for different types. Overloading is also not overriding; overriding happens between a superclass and its subclass, is resolved at runtime, and the inheritance and polymorphism article separates the two carefully.

How Real Systems Do This

The JDK is the best overload catalog in existence. String.valueOf has nine overloads, Math.abs has four, and List.of accepts zero to ten fixed arguments before falling back to varargs. Each name means exactly one idea, which is why the overloads feel invisible in use.

In my experience, the worst method I ever inherited was named process(): 180 lines, eleven parameters, and three boolean flags that changed its meaning. We split it into eight named methods before we could change anything safely, and the bug count in that area dropped close to zero for the following year. The lesson stuck: a method that needs flag parameters is asking to become several methods.

Methods are also your test seam. Every test you write in JUnit 5 calls a method with inputs and asserts on the output. Small, honest methods make tests read like documentation; sprawling ones make tests that need their own tests.

Decision Framework

1. Have you written the same logic twice? Extract a method now; the third copy is where the copies start to diverge.
2. Is the operation a pure function of its inputs? Keep it static and stateless until Part 2’s objects give it a home.
3. Same operation on different types? Overload the name with matching semantics.
4. Different operation with a similar shape? Use a different name; similarity is not identity.
5. Variable number of same-typed arguments? Varargs. Heterogeneous values? Explicit parameters, or a record.
6. More than four parameters? Introduce a parameter object; the records article makes that a two-line fix.

When NOT to Use This

• Do not overload when semantics differ. add(int) that increments and add(String) that appends force every caller to slow down at every call site; prefer two clear names.
• Do not use Object… varargs to accept anything. You trade compile-time checking for runtime ClassCastException risk, and you almost never want that trade.
• Do not extract a single-use one-liner when it breaks the flow of the story. Local readability can beat reuse, especially inside short main methods.
• Do not smuggle results out through mutated parameters. Return a value or a record instead; output parameters make callers reverse-engineer the contract.

Common Mistakes

• Believing Java passes objects by reference. Reassigning the parameter is invisible to the caller; mutating the object is not.
• Overloads that differ only by return type: the file does not compile, because return type is not part of the signature.
• Ambiguous calls under widening: print(1, 2) fails when both (int, long) and (long, int) exist.
• Placing varargs before other parameters: int… values, int extra does not compile; varargs go last.
• Side effects hidden inside get-prefixed methods. Readers assume queries are safe, and audits turn into archaeology.
• Boolean flag parameters: send(invoice, true) reads like a riddle; sendUrgently(invoice) reads like a sentence.

Key Takeaways

• A method signature is the name plus parameter types; the return type is not part of it, so it cannot distinguish overloads.
• Java is pass-by-value, always. Primitives copy values; objects copy references, so mutation is visible and reassignment is not.
• Every non-void method must return on all paths, and the compiler enforces that proof.
• Overload one name only when every version means the same thing for different types.
• Varargs accept any number of same-typed arguments and must be the last parameter.
• Guard returns beat nesting; small methods with honest names are the unit of reuse and of testing.
• Replace long parameter lists and boolean flags with clear methods or parameter records.

FAQ

What is a method signature in Java?

The signature is the method name plus the parameter types: area(double). Modifiers, the return type, and parameter names are excluded, which is why overloads cannot differ by return type alone.

Is Java pass by value or pass by reference?

Java is always pass by value. For objects, the value passed is a copy of the reference, so the method can mutate the shared object but can never reassign the caller’s variable.

What is method overloading in Java?

One method name with several parameter lists, resolved at compile time by the most specific match. Use it when every overload implements the same idea, such as Math.abs for int, long, float, and double.

Can a Java method return multiple values?

Not directly. Return a record or an array instead, which Part 2’s records make a one-line solution, and name the fields so the return value documents itself.

What does void mean in Java?

It means the method returns no value. A bare return; statement can exit early, but the method cannot return data.

Conclusion

Methods in Java turn logic into named, reusable, testable units, and everything you build from here, from the calculator to the capstone REST API, is methods all the way down. The rules are few: copy semantics you can explain, signatures that are honest, and bodies small enough to hold in your head.

A method earns its existence twice: once when you write it, and once when a stranger understands it in ten seconds.

Last updated on 28 September 2026.