App.java:12: error: cannot find symbol

The exact error string

App.java:12: error: cannot find symbol
        System.out.println(usrName);
                            ^
  symbol:   variable usrName
  location: class App
1 error

The symbol: line names exactly what javac was looking for — here, a variable called usrName — and its kind (variable, method, or class). The location: line names the scope it searched: class App means it looked through the entire App class and found nothing matching. These two lines, read together, are almost always enough to identify which of the causes below applies without needing to reason through the rest of the file.

Cause 1: a typo in the identifier name

String userName = "Ada";
System.out.println(usrName);   // ❌ cannot find symbol: variable usrName

// ✅ match the exact spelling of the declared variable
System.out.println(userName);

The simplest and most common cause, identical in spirit to Go's "undefined: X" — javac's identifier resolution is exact-match only, with no fuzzy correction at the compiler level (though most IDEs highlight this live and suggest the closest declared name as you type). A single dropped, transposed, or miscapitalized letter produces this error with the symbol: line showing exactly the misspelled name you wrote, which is often the fastest way to spot the typo — compare it letter-by-letter against the actual declaration.

Cause 2: the variable exists, but in a different (narrower) scope

public void process(boolean valid) {
    if (valid) {
        String result = "OK";   // scoped to this if-block only
    }
    System.out.println(result);   // ❌ cannot find symbol: variable result
}                                  //    (out of scope the moment the block ends)

// ✅ declare it in the outer scope so it's visible where it's needed
public void process(boolean valid) {
    String result = "";
    if (valid) {
        result = "OK";
    }
    System.out.println(result);
}

Every block delimited by { } in Java — the body of an if, for, while, or a bare block — defines its own scope, and a variable declared inside one ceases to exist the instant that block's closing brace is reached. This is easy to miss because the variable is textually right there, a few lines above the failing reference; the compiler, however, only sees a declaration whose lifetime already ended by the time execution (and name resolution) reaches the line that tries to use it.

Cause 3: a method call whose arguments don't match any existing overload

class Calculator {
    int add(int a, int b) { return a + b; }
}

Calculator calc = new Calculator();
calc.add(1, 2, 3);   // ❌ cannot find symbol
                      //   symbol: method add(int,int,int)
                      //   location: class Calculator

// ✅ call it with the argument types/count an actual overload accepts
calc.add(1, 2);
// or add a genuinely new overload if 3-argument addition is intended:
int add(int a, int b, int c) { return a + b + c; }

This is the case most likely to look like a compiler mistake at first glance — the method visibly exists in the source, right there in the class. But the symbol: line is precise: it names not just add but add(int,int,int), the exact signature it looked for and failed to find, because javac performs overload resolution against the specific number and types of arguments at the call site. A method with the right name but a different parameter list simply isn't a match; from the resolver's perspective, the three-argument version of add genuinely doesn't exist yet.

Cause 4: a type used without its import (and it's not in java.lang)

public class App {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();   // ❌ cannot find symbol
    }                                                //   symbol: class List
}                                                     //   location: class App

// ✅ import the types from java.util
import java.util.List;
import java.util.ArrayList;

Only the classes in java.lang (String, Object, Integer, and a handful of others) are available without an explicit import — everything else, including extremely commonly used types like List or ArrayList from java.util, must be imported (or referenced by its fully-qualified name) in every file that uses it. The location: line for this variant typically names the current class itself, since the compiler is treating the bare type name as if it should already be resolvable and finding nothing that matches within the file's own visible scope.

Common causes at a glance

Why this happens: javac reports what it searched, not just what it expected

Unlike a runtime NullPointerException, which tells you where a null value was dereferenced but not why it was null, javac's "cannot find symbol" is deliberately structured to report the search itself: exactly what name and kind it was resolving (the symbol: line), and exactly where it looked (the location: line). This design reflects how Java's name resolution actually works internally — every identifier reference is resolved against a specific enclosing scope, and printing that scope explicitly turns an otherwise generic "not found" message into a precise diagnostic. It's also why a single early typo can cascade into a wall of errors: once one identifier fails to resolve, the compiler doesn't know its type, and everything downstream that depended on that unknown type can independently fail to resolve too — fixing the very first "cannot find symbol" in a long error list and recompiling is usually far more productive than trying to address every reported error individually.

Debugging checklist

• ✓ Read the symbol: and location: lines, not just the top message
• ✓ If it names a variable that's visibly declared nearby, check whether it's inside a narrower { } block
• ✓ If it names a method with a full parameter list, confirm your call's argument types actually match an existing overload
• ✓ If it names a class, confirm the import statement for that type's package is present
• ✓ Fix the first cannot-find-symbol error in the file first, then recompile — later ones often disappear on their own