Methods, Calls, Recursion, and Overloading

Arguments are evaluated before the call

Consider this program:

static int announce(int value) {
    System.out.println("evaluated " + value);
    return value;
}

static void show(int left, int right) {
    System.out.println(left + right);
}

public static void main(String[] args) {
    show(announce(2), announce(5));
}

Java evaluates argument expressions from left to right. The output is:

evaluated 2
evaluated 5
7

Only after both argument values exist does show begin.

Java always passes values

For a primitive, the value is the primitive data:

static void change(int number) {
    number = 99;
}

int original = 10;
change(original);
System.out.println(original);  // 10

The parameter receives a copy of 10. Assigning 99 changes only the parameter.

For an array or object, the value is a reference:

static void changeFirst(int[] numbers) {
    numbers[0] = 99;
}

int[] original = {10, 20};
changeFirst(original);
System.out.println(original[0]);  // 99

The parameter receives a copy of the reference. Both references reach the same array, so mutation is visible through either one.

Reassigning the parameter is different:

static void replace(int[] numbers) {
    numbers = new int[] {99, 100};
}

int[] original = {10, 20};
replace(original);
System.out.println(original[0]);  // 10

The parameter now points elsewhere. The caller’s variable still holds its original reference.

Java is therefore pass-by-value in both examples. The type of value differs.

Local variables have method scope

Parameters and variables declared inside a method are local to that invocation.

static int square(int value) {
    int result = value * value;
    return result;
}

Neither value nor result can be named from main. A later call gets new locals, even if an earlier call used the same values.

Local variables do not receive automatic default values. A local must definitely be assigned before Java lets you read it.

static int choose(boolean first) {
    int result;
    if (first) {
        result = 10;
    }
    return result; // compile-time error: result may be uninitialised
}

The compiler examines paths, not your intention. There is a path where first is false and no assignment occurs.

Every active call has a stack frame

The call stack records methods that have started but not finished. A call adds a frame. Returning removes that frame.

static int doubleValue(int n) {
    return n * 2;
}

static int addThenDouble(int a, int b) {
    int sum = a + b;
    return doubleValue(sum);
}

public static void main(String[] args) {
    int answer = addThenDouble(3, 4);
}

At the deepest point, the stack is:

top     doubleValue: n = 7
        addThenDouble: a = 3, b = 4, sum = 7
bottom  main

doubleValue returns 14, so its frame is removed. addThenDouble then returns 14, and its frame is removed.

A frame holds bookkeeping needed for that invocation. This includes parameters, local values, operand data, and a return point in the JVM model.

This model explains stack traces. The top entry is where the failure occurred. Lower entries show the unfinished callers that led there.

Recursion is an ordinary method calling itself

static int factorial(int n) {
    if (n < 0) {
        throw new IllegalArgumentException("n must be non-negative");
    }
    if (n <= 1) {
        return 1;
    }
    return n * factorial(n - 1);
}

A correct recursive method needs two properties:

1. A base case that returns without another recursive call.
2. A recursive step that moves the input toward that base case.

Trace factorial(4) before running it:

factorial(4) waits for 4 * factorial(3)
factorial(3) waits for 3 * factorial(2)
factorial(2) waits for 2 * factorial(1)
factorial(1) returns 1
factorial(2) returns 2
factorial(3) returns 6
factorial(4) returns 24

The calls grow the stack on the way down. Returns unwind it on the way back.

If the input never reaches a base case, each unfinished call adds another frame. Eventually the thread cannot create another frame and throws StackOverflowError.

Java does not promise tail-call elimination. A recursive solution that may be extremely deep should usually become a loop or use an explicit data structure.

Overloading gives one name to several parameter lists

These methods are overloads:

static int area(int side) {
    return side * side;
}

static int area(int width, int height) {
    return width * height;
}

static double area(double radius) {
    return Math.PI * radius * radius;
}

An overload must have a different parameter list. The method’s signature consists of its name and parameter types.

Parameter names and return types do not distinguish overloads:

static int parse(String text) { return 1; }
static double parse(String value) { return 1.0; } // duplicate signature

The compiler chooses an overload using the compile-time types of the argument expressions. The return destination does not choose it.

A practical overload-resolution sequence

For a fixed call, use this sequence:

1. Look for applicable fixed-arity methods under strict invocation. Exact matches and primitive widening are available here.
2. If none apply, allow loose invocation conversions such as boxing and unboxing.
3. If none apply, consider variable-arity methods.
4. If several methods survive one phase, choose the most specific applicable method.
5. If there is no unique most specific method, the call is ambiguous.

static void pick(long value)    { System.out.println("long"); }
static void pick(Integer value) { System.out.println("Integer"); }
static void pick(int... values) { System.out.println("varargs"); }

pick(1); // long

The literal 1 has type int. Primitive widening to long is available in the first phase. Boxing is not considered because an applicable method already exists.

Varargs are syntax for receiving an array:

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

sum();
sum(4);
sum(4, 5, 6);

Inside sum, values has type int[]. At a variable-arity call site, the compiler arranges the supplied values into an array.

Declared types can change overload selection

static void describe(Object value) { System.out.println("object"); }
static void describe(String value) { System.out.println("string"); }

String text = "hi";
Object general = text;

describe(text);    // string
describe(general); // object

Both variables refer to the same object. Overloading is still chosen from their compile-time types.

Overriding behaves differently because it uses the object’s run-time class. Phase VII separates those mechanisms in full.

null can expose ambiguity:

static void load(String value) { }
static void load(Integer value) { }

// load(null); // ambiguous: neither parameter type is more specific than the other

The compiler refuses to guess.