Scope: where variables live

Written Explanation

Scope: the braces rule

The scope of a variable is the region of code where its name can be used. For a local variable the rule is simple: from its declaration to the closing brace } of the block that contains it. The Java Language Specification says a local variable declared in a block is in scope for the rest of that block, and that a method parameter is in scope in the whole body of its method.

static void demo(int n) {          // n is in scope in the whole method
    int a = 1;                     // a: from here to the end of demo
    for (int i = 0; i < n; i++) {  // i: only inside the for
        int square = i * i;        // square: only inside this loop body
    }
    // i and square no longer exist here
}

Consequences:

• A variable declared in a method is local to that method. Another method cannot see it, even if the names match. Two methods can each have their own count, and they are unrelated.
• A variable declared inside a loop or an if block lives only in that block, as square does above.
• You cannot declare a second variable of the same name while the first is still in scope. That includes a parameter: declaring int n in the body of a method that already has a parameter n is an error.

Real compiler messages for these mistakes (JDK 21):

error: variable n is already defined in method f(int)
error: cannot find symbol
        System.out.println(i);        // i was declared inside the for
  symbol:   variable i
  location: class Err
error: variable total is already defined in method main(String[])

If you see "cannot find symbol" for a variable you are sure you declared, check the braces: you are probably using it outside its block.

Each call gets fresh variables

Local variables are created when the method runs and discarded when it returns. Calling the method again starts from scratch. This is why a counter inside a method never counts across calls:

static int counter() {
    int count = 0;
    count++;
    return count;
}

Calling counter() twice returns 1 both times: each call makes a new count that starts at 0. To carry a value from one call to the next, you must pass it in and return it, or (much later in the course) store it somewhere that outlives the method. Lesson 5 shows where each call's variables are kept.

Pass-by-value: methods get copies

When you call addOne(n), Java evaluates the argument and copies the value into the parameter. The parameter is a separate variable. Changing it changes only the copy.

The Oracle tutorial states it directly: primitive arguments are passed by value, and a change to the parameter inside the method is lost when the method returns. In its example the parameter is set to 10, yet the caller's variable still prints 3.

Recipe-card view: you give the second cook a photocopy of your shopping list. They can scribble all over the copy; your list is untouched.

This is the reason a method like this cannot change its caller's number:

static void addOne(int x) {
    x = x + 1;        // changes the copy only
}

If the caller needs the new value, return it and let the caller assign it: n = addOneAndReturn(n);. That is the same compute-and-return habit from Lesson 2.

For the same reason you cannot write a method that swaps two int variables of its caller: it swaps its two copies and returns, and nothing outside changes.

What about references?

Values of type String and the other non-primitive types you will meet (arrays, objects) are held through references: the variable holds a pointer to the thing, not the thing itself. Java passes references by value too. What is copied is the reference, so the parameter and the caller's variable both point to the same object.

Two consequences, matching the Oracle tutorial:

1. If the method uses the reference to change the object it points to, the caller sees the change, because there is only one object.
2. If the method assigns a new object to the parameter, only the copy of the reference is redirected. The caller's variable still points to the original object.

String is immutable (its contents never change), so a method cannot modify the caller's String at all: operations such as toUpperCase() return a new String and leave the original alone. Arrays arrive in Module 15; the short example below is a preview so you can see both consequences. If it feels unfamiliar, skim it and come back after that module.