What Are the Variable Scopes in Java?

Java has four practical levels of scope, and they nest.

Block scope covers local variables, method parameters and the resources of a try-with-resources block. A local variable is visible from its declaration to the end of the enclosing block, and cannot be used before that declaration point. Because a for loop body is its own block, the loop variable of an enhanced for is not visible after the loop, which is a genuinely useful property.

Method scope is the frame of a method: parameters and locals live here and die when the method returns. Nothing declared inside a method is visible to another method.

Class scope covers the fields of a class, which live as long as the instance does. Instance fields belong to an object; static fields belong to the class and are shared by every instance and by the class itself.

Two rules complete the picture. A local variable may shadow a field: the local wins inside its block, and the field is unreachable there without qualification. And a field declared in a superclass is visible in a subclass, though it may be shadowed by a field of the same name declared in the subclass.

The other thing to remember is lifetime versus scope. Scope decides where you can name a variable; lifetime decides how long the value survives. A static field has class lifetime but is not in scope for code that does not reference the class by name, and a local variable in a dead block is still in scope for the compiler even though its value is gone.

Because an instance field only exists as part of a particular object. A static method is invoked without any object in hand — the JVM calls it on the class, not on an instance — so there is nothing for it to read the field from. The compiler rejects the direct reference with the message that a non-static variable cannot be referenced from a static context.

The rule is not a limitation but a warning about design. A static method that needs instance state is really a method of an instance, and declaring it static means the caller has to supply the object somehow, which usually means passing it in as an argument. If the method needs the state often, it should be an instance method instead.

public class Main {
    private int counter = 0;
    static int instances = 0;

    public static void main(String[] args) {
        // System.out.println(counter);   // compile error: non-static variable
        //                                  // cannot be referenced from a static context

        Main m = new Main();
        m.counter = 7;
        System.out.println("instance field : " + m.counter);

        // Static state is shared by every instance of the class.
        System.out.println("instances now  : " + Main.instances);
        m.bumpStatic();
        Main other = new Main();
        other.bumpStatic();
        System.out.println("after two bumps: " + Main.instances);
    }

    void bumpStatic() {
        instances++;
    }
}

Two related facts round out the answer. Inside an instance method you can still touch static state directly through the class name, and you may also write the field name unqualified — the compiler resolves it to the class field. And the reverse situation is fine: an instance method may read both instance fields and static fields, because the instance is available there. If a static method genuinely needs instance state, pass the object in as a parameter, or move the behaviour to the instance where it belongs.

Shadowing happens when a local variable or parameter has the same name as a field. Inside the scope of the local, the local wins, and the field becomes unreachable without qualifying it. Java permits this without any warning, unlike some other languages.

The danger is not that the code fails to compile — it compiles and behaves consistently. The danger is that the method quietly operates on a different value than the one the field holds, so an assignment to the local never reaches the field and the object state never changes. A constructor that takes a parameter named exactly like the field and assigns the field to itself is the canonical example.

How to avoid it

There are three habits, in increasing order of strictness. First, rename the parameter — use this.x = x is the fix, but this.count = count reads badly, so prefer a distinct name such as newCount. Second, qualify with this when the intent really is the field, which makes the assignment explicit even if the names collide. Third, use a static analysis check in the build: most IDEs can flag parameters and locals that hide fields, and checkstyle has a HiddenField rule that fails the build on exactly this pattern.

Shadowing also happens between a subclass field and a superclass field of the same name. The subclass field wins inside the subclass, and the superclass value is still there but must be reached through super. That situation is genuinely a design smell, because the two fields hold two different values, and the standard advice is to rename one of them or to remove the subclass field entirely.