Variable shadowing occurs when a local variable or parameter has the same name as an instance variable; inside that constructor or method, the name refers to the local variable, not the instance variable (EK 3.8.A.2). The instance variable is hidden, or "shadowed," until the block ends.
Variable shadowing is what happens when a local variable or parameter inside a method or constructor has the same name as an instance variable of the class. Java doesn't crash or warn you. It just quietly picks the most local version of the name. So inside that block, value means the local value, and the instance variable value is invisible, or "shadowed." The CED states this directly in EK 3.8.A.2: when names collide, the variable name refers to the local variable instead of the instance variable.
Think of it like two people named Alex in a room. If your friend Alex is standing right next to you, that's who answers when you call the name, even if there's another Alex across the building. The closer scope wins. The classic place you see this is in constructors like public Student(String name, int grade), where the parameters name and grade shadow the instance variables with the same names. That's exactly why you write this.name = name; to say "the instance variable named name gets the parameter named name." Without this, the line name = name; would just assign the parameter to itself and the instance variable would stay unchanged.
Variable shadowing lives in Topic 3.8 (Scope and Access) in Unit 3: Class Creation, supporting learning objective 3.8.A, which asks you to explain where variables can be used in code. EK 3.8.A.1 establishes that local variables (including parameters) only exist inside their block, and EK 3.8.A.2 is the shadowing rule itself. This matters because Unit 3 is where you start writing your own classes, and almost every constructor you write will have parameters that shadow instance variables. If you don't understand shadowing, this.name = name; looks like magic. Once you do understand it, you can trace any code segment where the same name appears in two scopes, which is exactly what scope-based multiple choice questions test.
Keep studying AP® Computer Science A Unit 3
The this Keyword (Unit 3)
Shadowing is the problem; this is the solution. When a parameter hides an instance variable, this.value reaches past the local variable to grab the object's own copy. Constructors use this pattern constantly.
Local Variables and Parameters (Unit 3)
Shadowing only makes sense once you know that parameters count as local variables (EK 3.8.A.1). A parameter named grade is a local variable named grade, so it follows the same scope rules and can shadow an instance variable just like a variable declared in the method body.
Constructors and Instance Variables (Unit 3)
The standard AP constructor pattern, where parameter names match instance variable names on purpose, is intentional shadowing. You're expected to recognize it and resolve it correctly with this when writing class FRQs.
Method Decomposition and Calling Methods (Unit 3)
Shadowing is method-by-method, not class-wide. If method1 declares a local value and then calls method2, method2 still sees the instance variable. The shadow ends where the block ends. Practice questions love testing exactly this handoff.
Variable shadowing shows up almost exclusively in multiple choice questions that make you trace code. A typical stem gives you a class with a private instance variable like private int value = 10;, one method that declares a local int value = 20;, and another method that doesn't. Then it asks what gets printed. The trap is assuming the local variable in one method affects the other method. It doesn't. The method with the local variable prints 20; the method without it prints 10. On the FRQ side, no released free-response question tests shadowing as its own skill, but it shows up implicitly every time you write a constructor or setter on the Class question. If your parameter is named name and you write name = name; instead of this.name = name;, your instance variable never gets set, and that costs points. The safe habits are either using this or giving parameters different names.
Both involve one thing "hiding" another with the same name, but they're completely different mechanisms. Shadowing is about variables and scope within a single class. A local variable temporarily hides an instance variable inside one block. Overriding is about methods and inheritance across classes, where a subclass replaces a superclass method's behavior. Shadowing is resolved by where you are in the code; overriding is resolved by what type of object you have.
When a local variable or parameter shares a name with an instance variable, the name refers to the local variable inside that block (EK 3.8.A.2).
Parameters count as local variables, so constructor parameters like name and grade shadow instance variables with the same names.
Use the this keyword (this.name = name;) to assign a shadowing parameter's value to the instance variable; writing name = name; just assigns the parameter to itself.
Shadowing only applies inside the block where the local variable is declared. Other methods in the class still see the instance variable.
When tracing code on multiple choice questions, check each method separately and ask whether a local variable with the same name exists in that specific method.
It's when a local variable or parameter has the same name as an instance variable, so inside that method or constructor the name refers to the local variable instead. Per EK 3.8.A.2, the local variable always wins inside its own block.
No. Java compiles and runs the code without complaint. It simply uses the most local variable with that name, which is exactly why shadowing causes silent logic bugs instead of error messages.
Out of scope means a variable doesn't exist at that point in the code, which causes a compile error if you try to use it. Shadowing means two variables with the same name both exist, and Java picks the local one. The instance variable is still alive, just hidden.
Because the parameter name shadows the instance variable name inside the constructor. this.name explicitly means the instance variable, so this.name = name; copies the parameter into the object's field. Without this, name = name; assigns the parameter to itself and does nothing useful.
No. The instance variable keeps its value the whole time. A class with private int value = 10; still prints 10 from any method that doesn't declare its own local value, even if another method declared int value = 20;.
Connect this key term to the AP exam workflow: review the course, practice questions, and check related study tools.
Review units, study guides, and course resources.
Check this vocabulary in multiple-choice context.
Apply key concepts in written AP responses.
Estimate the exam score you are working toward.
Review the highest-yield facts before practice.
Put the full course together before test day.