Java Objects, Nested Classes and Garbage Collection (1Z0-831)

An object exists only when an expression such as new Account() runs; declaring a variable creates a reference, never an object. A reference is a value that either points to one object or is null. new allocates the object, sets every field to its default (0, false, '\u0000' or null), runs the constructor chain and returns a reference to the result.

class Account {
    int balance;
    String owner;
}

public class Main {
    public static void main(String[] args) {
        Account a;                 // a reference, no object
        Account b = new Account(); // one object
        a = b;                     // still one object
        System.out.println(b.balance + " " + b.owner);
        System.out.println(a == b);
    }
}

This prints 0 null and then true. Only one Account object exists: a and b are two references to it, and == on references compares identity (the same object), not contents.

• Count objects by counting new expressions that actually run (plus array creations and array initializers), never by counting variables. Lamp l1, l2 = new Lamp(); declares two references and creates one object.
• A reference field that nothing assigns stays null. Calling a method through it (order.customer.name() when customer was never set) compiles, then throws NullPointerException at runtime.
• A local variable gets no default: reading it before it is definitely assigned is a compile error, not a null.

When two variables hold the same reference they are aliases (say Tank t2 = t1;): a change made through either one changes the single shared object, while assigning a new reference to one variable changes only that variable. Keep the two operations apart when you trace code:

A reliable way to trace is to draw each object as a box and each variable as an arrow. Field assignments write inside a box; variable assignments move an arrow. Anything you compute afterwards reads the box the arrow currently points to.

Java passes every argument by value, and for an object type the value copied is the reference. The method's parameter therefore starts as another alias of the caller's object: it can mutate that object, but reassigning the parameter only reseats the method's own copy and never reaches the caller's variable.

class Wallet {
    int coins;
}

public class Main {
    static void spend(Wallet w) {
        w.coins -= 3;      // reaches the caller's object
        w = new Wallet();  // reseats only the parameter
        w.coins = 50;      // lands on the new object
    }

    public static void main(String[] args) {
        Wallet mine = new Wallet();
        mine.coins = 20;
        Wallet shared = mine;  // alias: same object
        spend(shared);
        System.out.println(mine.coins + " " + shared.coins);
    }
}

The program prints 17 17. Inside spend, w.coins -= 3 lands on the one object that mine and shared both point to; after w = new Wallet() the parameter points to a brand-new object, so w.coins = 50 changes something the caller never sees. Two general rules follow:

• Assignments to parameters never travel back. However a method reassigns or exchanges its parameters, the caller's variables still refer to exactly the objects they referred to before the call.
• A field write goes to whatever object the parameter refers to at that moment. Trace each parameter's arrow line by line: if it currently points at one of the caller's objects, the write is visible to the caller; if it points at an object the method created, it is not.

A nested class is any class declared inside another class or block, and Java has four kinds that differ in whether they need an enclosing instance and where they can be created. A static nested class is declared with static at member level; every other nested class is an inner class — a non-static member class, a local class or an anonymous class.

Member records, enums and interfaces are implicitly static. A record declared inside a class is a static nested type even without the keyword, so its methods cannot read the outer class's instance fields (non-static variable … cannot be referenced from a static context). Local records, enums and interfaces are implicitly static too, so they cannot capture the enclosing method's local variables.

An inner class object can only be created with an enclosing object to bind to, while a static nested class object needs none. Outside the outer class, or from a static method, you supply the enclosing instance with the qualified form outerRef.new Inner(); the type is written Outer.Inner.

class Garage{
    private int opens;
    private static int visits = 10;

    class Door {           // needs a Garage instance
        void open() { opens++; }
    }

    static class Inspector {  // no Garage instance
        String report(Garage g) {
            return g.opens + "/" + visits;
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Garage g = new Garage();
        Garage.Door d = g.new Door();
        d.open();
        d.open();
        Garage.Inspector i = new Garage.Inspector();
        System.out.println(i.report(g));
    }
}

This prints 2/10: two calls through the Door bound to g raised g's private opens field, and the static nested Inspector read it through the explicit reference it was given. The legal and illegal forms are near-twins, so learn them precisely:

• new Outer().new Inner() and ref.new Inner() compile — any expression of type Outer can be the enclosing instance.
• new Outer.Inner() only names the type more fully; it does not supply an enclosing instance. In a static method it fails exactly like new Inner(): non-static variable this cannot be referenced from a static context.
• new Inner() or this.new Inner() inside a static method fails: non-static variable this cannot be referenced from a static context. Inside an instance method, plain new Inner() works because it means this.new Inner().
• new ref.Inner() is not the syntax — the compiler reads ref as a package or type name.
• new Outer().new Nested() for a static nested class fails (qualified new of static class); use new Outer.Nested().

The binding is permanent: every inner object created from one outer object reads and writes that outer object's fields, so two inner objects made from the same outer object share its state, while one made from another outer object does not. A static nested class reaches the outer class's static members directly (even private ones) but its instance members only through an explicit reference. Since Java 16 an inner class may also declare static members; a static field in an inner class is one variable shared across every enclosing instance.

When an inner class declares a field with the same name as one in its enclosing class, the nearest declaration wins and Outer.this.name reaches the shadowed one. Inside an inner class, a simple name resolves to the innermost declaration: a parameter or local first, then the inner class's own field, then each enclosing class outwards. this always means the current (innermost) object; ClassName.this means the enclosing instance of that class.

class Shop {
    String label = "shop";

    class Shelf {
        String label = "shelf";

        class Slot {
            String label = "slot";

            String where(String label) {
                return Shop.this.label + "/" + Shelf.this.label
                    + "/" + this.label + "/" + label;
            }
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Shop shop = new Shop();
        Shop.Shelf.Slot slot = shop.new Shelf().new Slot();
        System.out.println(slot.where("tag"));
    }
}

This prints shop/shelf/slot/tag. Each level of nesting has its own enclosing object, so with two levels Shop.this and Shelf.this are different objects, and the bare name label is the parameter because it is the innermost declaration. ClassName.this is a reference to the real enclosing object, not a copy taken when the inner object was created: whatever value that object's field holds at the moment of the read is what you get.

A local or anonymous class may read a local variable or parameter of its enclosing method only if that variable is final or effectively final — assigned once and never reassigned anywhere, before or after the class. Reassigning a captured variable is a compile error: local variables referenced from an inner class must be final or effectively final. Lambdas follow the same rule.

• Loop variables. A classic for index is reassigned by its update expression, so it is not effectively final and cannot be captured; declaring it final just moves the error to the update. A variable declared inside the loop body and assigned once is a new, effectively final variable on each iteration, and so is the variable of an enhanced for — both can be captured.
• An anonymous class can extend an abstract class: new Base(args) { … } passes the arguments to the superclass constructor and must implement its abstract methods. It cannot declare a constructor of its own; an anonymous class implementing an interface takes no arguments.

import java.util.function.Supplier;

class Radio {
    String tag = "radio";

    void tune() {
        String suffix = "!";   // effectively final
        Supplier<String> anon = new Supplier<>() {
            String tag = "dial";

            public String get() {
                return this.tag + "," + Radio.this.tag + suffix;
            }
        };
        Supplier<String> lambda = () -> this.tag + suffix;
        System.out.println(anon.get());
        System.out.println(lambda.get());
    }
}

public class Main {
    public static void main(String[] args) {
        new Radio().tune();
    }
}

This prints dial,radio! and then radio!. Inside an anonymous class body, this is the anonymous object itself (so this.tag is its own field, and Radio.this.tag reaches the outer one); inside a lambda, this is the enclosing Radio instance, because a lambda does not introduce a new object scope. The same split applies to an overridden toString() printed through this.

An object is eligible for garbage collection as soon as no live thread can reach it through any chain of references from a root. Roots are the local variables and parameters of methods that are still running, static fields of loaded classes and live threads. An object's life cycle is therefore: created by new, used while reachable, eligible once unreachable, and reclaimed at some later time the JVM chooses.

class Wagon {
    Wagon coupled;
}

public class Main {
    public static void main(String[] args) {
        Wagon front = new Wagon();   // wagon 1
        Wagon rear = new Wagon();    // wagon 2
        front.coupled = rear;
        rear.coupled = front;        // a cycle
        Wagon spare = new Wagon();   // wagon 3
        spare.coupled = new Wagon(); // wagon 4
        rear = null;
        front = null;                // 1 and 2: unreachable island
        spare = spare.coupled;       // 3: unreachable; 4: held
        System.out.println("parked");
    }
}

When parked is printed, wagons 1, 2 and 3 are eligible and wagon 4 is not (variable spare now holds it). Rules for tracing:

• Only references from reachable things count. Wagons 1 and 2 point at each other, but nothing reachable points at either — an island of isolation, collectable however many references it holds internally. Add one incoming reference from a live variable or object and the whole island is reachable again.
• Setting one reference to null makes an object eligible only if it was the last path to it.
• Arrays are objects. Count the array itself, and an element is eligible once neither the array (if reachable) nor any variable refers to it.
• Method exits end local references, but an object a method stored in a static field or returned to a caller who kept it stays reachable.

System.gc() (the same as Runtime.getRuntime().gc()) only suggests that the JVM expend effort recycling unused objects; it guarantees nothing. The Java SE API documentation says there is no guarantee it reclaims any particular objects or amount of space, or completes at any particular time — before the call returns or ever. Two consequences follow:

• Eligibility and reclamation are different events. Your code decides eligibility by dropping references; the JVM decides if and when to reclaim. A reference cycle that is unreachable is eligible whether or not any collection ever runs.
• Never rely on collection for program logic. Object.finalize() has been deprecated for removal since Java 18; release resources explicitly, for example with try-with-resources.

An inner class object is tied to its enclosing instance, so as long as the inner object is reachable, the outer object it uses is reachable too. Storing an inner object in a long-lived place — a static field, a listener list, a cache — therefore keeps the whole outer object (and everything it references, such as a large buffer) out of reach of the collector, even after every direct reference to the outer object is gone.

Under the hood the compiler stores the enclosing instance in a hidden final field (shown by javap -p as this$0). Since JDK 18, javac omits that field when the inner class never uses its enclosing instance (serializable inner classes excepted), so an inner class that touches no outer member no longer pins its outer object. Reason about code that does use outer members (as exam snippets do) as holding a reference. When an inner class does not need the outer object at all, declare it static: a static nested class has no enclosing instance and cannot cause this kind of leak.