4.1.1.13–4.1.1.14 - Local and global variable scope (Java)
Learn where a Java variable can be used, how each method call gets its own local state, and how shared state can make changes harder to reason about. Choose local variables and explicit parameters when a task does not need shared state. This Java route is incomplete: runnable support pending; source tasks are written practice with no Run.
Lifetime and visibility
A local variable is declared inside a method or one of its blocks; code outside its scope cannot refer to it by that name. Scope is the region of source where the name can be used. Lifetime is when its storage belongs to an active execution. These are related but different ideas.
static int doublePlusOne(int value) {
int result = value * 2;
return result + 1;
}
The parameter value and local result belong to this invocation. doublePlusOne(3) gives 7 and a later doublePlusOne(8) gives 17; the second call does not inherit the first call's result. In the source, result is usable from its declaration through the rest of the method body. A variable declared inside an if block cannot be used after that block closes. Java also requires a local variable to be definitely assigned before its value is read.
When the method returns, its call-local variables cease to belong to an active call. That does not imply an object referenced by a local variable must vanish: if another live reference still refers to the object, the object may remain available. It is the variable's local binding whose lifetime ends.
Java has no free-standing global variables outside classes. A field belongs to an object or, for a static field, to a class. A shared static field can perform the role often called a global variable in procedural algorithms, but its visibility still follows Java's access rules. An instance field belongs to one particular object, so different instances normally have separate field values.
Local state and side effects
Local variables isolate a method's intermediate work, while a side effect changes something beyond its returned value, such as a shared field, a supplied object's contents or printed output. Local names can therefore reduce accidental interference, but a local reference alone does not guarantee that a method has no side effects.
This class-level fragment declares a shared field and a method with a local variable of the same name:
static int total = 100;
static int addOne(int number) {
int total = number + 1;
return total;
}
addOne(4) returns 5; the class field stays 100. Inside the method, the local name shadows the field. Main.total would explicitly name the static field if this fragment is inside Main. Reusing names like this can be confusing even though it is legal; descriptive names are usually clearer.
Contrast a method that explicitly changes shared state:
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account