Java Method Parameters

The header and the call

In greet, name is the parameter. At the call, "Alice" is the argument. The call evaluates the argument, then the body runs with name holding that string reference.

static void greet(String name) {
    System.out.println("Hello, " + name);
}

greet("Alice");
greet("Bob");

Those two calls do not share a name variable. Each call has its own local variables. The first frame’s name refers to "Alice". The second frame’s name refers to "Bob". When a call returns, its parameter storage is discarded with the frame.

Arguments line up from left to right. schedule("Mira", 10, true) stores the string, then the hour, then the flag. schedule(10, "Mira", true) fails to compile: an int is not a String, and Java does not reorder arguments to make the types fit.

static void schedule(String studentName, int hour, boolean online) {
    System.out.println(studentName + " at " + hour + ":00, online=" + online);
}

schedule("Mira", 10, true);

What the type check allows

An exact type match is the easy case. A widening conversion is also allowed: an int argument may be passed to a long parameter, and a float to a double. The parameter receives the wider value. The caller’s variable, if it had one, keeps its original type and its original contents.

static void hold(long millis) {
    System.out.println(millis);
}

int delay = 40;
hold(delay);

A narrowing conversion does not happen on its own. Passing a long to an int parameter is a compile error unless the call casts, and the cast can drop high bits. That cast belongs at the call, where the loss is visible, rather than hidden inside a signature that only looked convenient.

Java does not give parameters default values. If online should be false when the caller omits it, write an overload with two parameters that calls the three-parameter method and passes false. Callers who need the flag use the longer signature. The names still do not travel to the call site.

static void schedule(String studentName, int hour) {
    schedule(studentName, hour, false);
}

After the value arrives

A parameter is already initialized when the body starts, which is why the body may read it immediately. A local declared in the body may not be read until some statement has assigned it. Mixing the two up leads people to “initialize” a parameter to a dummy value it will never keep. The call is the initialization.

final on a parameter forbids a later assignment to that variable. It is a promise to readers of the body: this name means the incoming value all the way down. It is not a promise about the object. If the parameter is a list, final still allows add.

static void announce(final String speaker) {
    System.out.println(speaker);
    // speaker = "someone else"; // compile error
}

The header is also the place to reject values the body cannot use. average divides by count. A count of zero is not a mysterious wrong answer later. It is an argument that breaks the contract, and the method can fail at the boundary with IllegalArgumentException before the division.

static double average(int total, int count) {
    if (count <= 0) {
        throw new IllegalArgumentException("count must be positive");
    }
    return (double) total / count;
}

A long list of parameters is a design signal. Callers cannot name them, and boolean flags become render(true), which hides whether true means draft, color, or something else. Group values that travel together into an object with fields, and let the method take that object. The call then reads as data, not as a sequence someone has to remember.