Method Inputs in Java: Understanding Parameters and Arguments

A parameter is a variable declared in the signature. An argument is a value supplied at the call. They are two sides of the same operation.

// DECLARATION: width and height are FORMAL PARAMETERS
public static int getArea(int width, int height) {
    return width * height;
}// CALL: 5 and 7 are ACTUAL ARGUMENTS
int area = getArea(5, HEIGHT);

Terms you will meet in textbooks: formal parameters means the declared names, actual parameters or arguments means the supplied values. They are the same two ideas under longer names, so if a book seems to contradict this page, it is almost certainly using a different word for the same slot.

Java has no named arguments. The first argument fills the first parameter, the second fills the second, and the compiler checks the types in order.

final int WIDTH = 5;
final int HEIGHT = 7;
getArea(WIDTH, HEIGHT);
// width is 5, height is 7
getArea(HEIGHT, WIDTH);
// width is 7, height is 5, same result here

Because of that, two parameters of the same type are easy to swap by accident and hard to notice, especially when both are the same primitive. drawBox(width, height) called as drawBox(HEIGHT, WIDTH) compiles happily and looks right in a square. Grouping related values into a small object removes the whole class of bug, which is why parameter objects are such a common refactoring.

One subtlety catches everyone: an int argument can be widened automatically to a long or a double, but a double passed to an int parameter is a compile error. Narrowing needs an explicit cast, and silently losing the decimal part is usually a bug rather than an intention.

This is the single most tested idea in methods, so it is worth being exact about. Java passes by value, always. What varies is whether the value being copied is a number or a reference.

public static void tryToChange(int number) {
    number = 99;
    // changes the local copy only
}public static void tryToChangeArray(int[] values) {
    values[0] = 99;
    // the caller DOES see this
    values = new int[VALUES];
    // the caller does NOT see this
}

Note the difference in tryToChangeArray. Writing values[0] modifies the shared array. Writing values points the local name at a different array, which only the method can see. The two lines look similar and mean very different things.

A parameter behaves like any other local variable. It exists from the moment the method is entered until it returns, and nothing outside can see or touch it.

public static int shadow(int value) {
    int doubled = value * 2;
    return doubled;
    // the parameter is gone once this ends
}int value = 10;
int result = shadow(value);
// the value held by the caller is intact

This scoping is a feature, not a limitation. Two methods can both use a variable called index without any interference, and no caller can accidentally modify another method’s working state.

When the number of values is genuinely unknown, add three dots. The compiler gathers the arguments into an array before entering the body.

public static int sum(int... values) {
    int total = 0;
    for (int value : values) {
        total = total + value;
    } return total;
}final int A = 1;
final int B = 2;
final int C = 3;
final int D = 5;
sum(A, B, C);
// 6
sum(D);
// 5
sum();
// 0, an empty array

Inside the method, values is simply a int[], so you can iterate it, index it, or pass it on to another varargs method.

A parameter declared final cannot be reassigned inside the method. The reference cannot be pointed somewhere new, although the object it points at can still be modified.

public static String describe(final String name, final int count) {
    name = "changed";
    // compile error, the parameter is final
    return name + count;
}public static void grow(final List<String> items) {
    items.add("new");
    // allowed, the list contents can change
    items = new ArrayList<>();
    // compile error
}

For a primitive final parameter, final and immutability are the same thing. For a reference, final only freezes the name, not the data, which is the distinction people most often miss.

Three habits keep signatures readable.

Name them for meaning, not type.calculateTax(amount, rate) reads clearly. calculateTax(double, double) does not, and the compiler will not help you if you swap them.

Keep the count low. Beyond three or four, the likelihood of swapping two arguments climbs sharply. Grouping related values into a small record or class fixes both the ordering risk and the documentation problem at once.

Do not return one parameter unchanged. A method that takes a value and hands back the same value is doing nothing, and the caller is better off keeping it.

Frequently Asked Questions

What is the difference between a parameter and an argument?

A parameter is a variable declared in the method signature, such as width in getArea(int width, int height). An argument is the value supplied at the call site, such as the 5 in getArea(5, height). The terms formal parameter and actual argument mean the same two things.

Does Java pass arguments by value or by reference?

Always by value, with no exceptions. What varies is what the value is: for a primitive it is the number itself, so changes are lost, while for an object it is the reference, so both sides still point at the same object and changes to its contents are shared.

Why does changing a parameter not update my variable?

Because the method received a copy. Java is pass by value, so reassigning the parameter only changes the copy the method is holding. The fix is either to return the new value or, for an object, to modify its contents rather than rebind the name.

What is varargs in Java?

A parameter declared with three dots, such as int... values, that accepts any number of arguments including none. The compiler collects them into an array before the method body runs, so inside the method values is simply an int array. It must be the last parameter.

Can a varargs parameter be followed by another parameter?

No. The varargs parameter must come last, because the compiler would otherwise have no way to know where the variable-length list ends. Putting another parameter after it is a compile error.

Does a final parameter make an object immutable?

No. It stops the reference being pointed at a different object, but the object it points at can still be modified. For a primitive parameter final and immutable are effectively the same thing, since there is no separate object to change.

How many parameters should a method take?

As few as possible, and past about three or four the risk of swapping two arguments of the same type rises sharply. Grouping related values into a small object or record removes that risk and makes the call site read better.

Can I pass an int where a double is expected?

Yes, that direction is safe because of automatic widening, and the int is promoted. The reverse is a compile error, because narrowing could lose the decimal part, so it needs an explicit cast and should only be used when that loss is genuinely intended.