What Does this Mean in Java?

this is a reference to the current object — the instance whose method or constructor is executing. It is an implicit parameter that every non-static method and constructor has, and it exists so you can refer to the current object explicitly.

There are four places you will actually use it. In a constructor, this.field = field distinguishes the field from a parameter of the same name. In a method, this.method() calls another method on the same object, which matters when a parameter shadows a method name. As this(...) in a constructor, it delegates to another constructor of the same class. And as a bare expression, return this; returns the current object, which is how a builder method or a fluent API returns itself for chaining.

Two restrictions are worth stating precisely. this cannot be used in a static method or in a static initializer block, because there is no current object in a static context — the compiler rejects it with the message that a non-static variable cannot be referenced from a static context. And in a constructor, this(...) must be the first statement, for the same reason super(...) must be: the object has to be fully set up before you delegate.

One thing this cannot do is change the static type of a reference. this always has the type of the current object at compile time, which is why you cannot assign it to a variable of a supertype and expect the compiler to forget the subclass methods.

Shadowing is not an error in Java, it is a silent trap. When a parameter has the same name as a field, the parameter wins inside the constructor, so owner = owner; assigns the parameter to itself and the field keeps its default value of null. The object is built, it looks fine from the outside, and the bug surfaces later as a null reference.

There are two standard fixes. The first is to qualify the field with this: this.owner = owner;. That makes the assignment explicit and the compiler will not let you get it wrong. The downside is that the line reads awkwardly — the same word on both sides of the assignment — and a reviewer has to notice the difference.

The second is to rename the parameter so that no collision exists at all: this.owner = accountOwner;. Now there is no ambiguity, no need for this, and the reader immediately sees which value came from the caller. This is the preferred style in most modern codebases, though it does not scale gracefully to constructors with eight parameters where you end up with a forest of names.

public class Main {
    public static void main(String[] args) {
        System.out.println(new Account("Ada", 100));
        System.out.println(new SavingsAccount("Grace", 250));
    }
}

class Account {
    private final String owner;
    private final int balance;

    // this.field = parameter: explicit, but reads awkwardly.
    Account(String owner, int balance) {
        this.owner = owner;
        this.balance = balance;
    }

    @Override
    public String toString() {
        return owner + " has " + balance;
    }
}

class SavingsAccount {
    private final String owner;
    private final int balance;

    // Renaming the parameter removes the ambiguity entirely.
    SavingsAccount(String accountOwner, int openingBalance) {
        this.owner = accountOwner;
        this.balance = openingBalance;
    }

    @Override
    public String toString() {
        return owner + " has " + balance;
    }
}

The third option, when the constructor has many parameters, is to stop having many parameters: take a builder, or use a static factory method with named steps. That removes the collision problem by changing the shape of the API rather than the spelling of the assignment.

They chain to different places. this(...) calls another constructor of the same class. super(...) calls a constructor of the superclass. When you write neither, the compiler inserts an implicit super() call to the superclass's no-argument constructor as the first statement.

A constructor may use either this or super as its first statement, but never both. The reason is structural: this(...) hands the work of initialising the object to another constructor of the same class, and that constructor is then responsible for calling super. If you wrote both, the superclass constructor would run twice, or the chain would be ambiguous.

Both delegate, but to different places. this(...) calls another constructor of the same class. super(...) calls a constructor of the superclass. When you write neither, the compiler inserts an implicit super() to the superclass no-argument constructor as the first statement.

A constructor may use either this or super as its first statement, but never both. The reason is structural: this(...) hands the work of initialising the object to another constructor of the same class, and that constructor is then responsible for calling super. If you wrote both, the superclass constructor would run twice, or the chain would be ambiguous.

Two rules catch people out. First, super(...) must also be the first statement, so you cannot assign a field before it — which is why you cannot set an inherited field directly in the constructor and must call a superclass method instead. Second, super without parentheses is a different thing entirely: it refers to the superclass object, so super.toString() calls the superclass implementation of that method and super.field reads a superclass field.

public class Main {
    public static void main(String[] args) {
        System.out.println(new Point(3, 4));
        System.out.println(new Point(5));
    }
}

class Point {
    private final int x;
    private final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
        System.out.println("Point(x, y) ran");
    }

    Point(int x) {
        this(x, 0);                 // this() delegates within the class
        System.out.println("Point(x) ran");
    }
}

class ColoredPoint extends Point {
    private final String colour;

    ColoredPoint(int x, int y, String colour) {
        super(x, y);               // super() delegates to the superclass
        this.colour = colour;
        System.out.println("ColoredPoint ran");
    }
}

Two rules catch people out. First, super(...) must also be the first statement, so you cannot assign a field before it — which is why you cannot set an inherited field directly in the constructor and must call a superclass method or setter instead. Second, super without parentheses is a different thing entirely: it refers to the superclass object, so super.toString() calls the superclass implementation of that method and super.field reads a superclass field.

The output shows the ordering that results from all of this. The subclass constructor always runs after the superclass constructor it delegates to, so a subclass can safely use inherited state that the superclass constructor has already initialised.