How does `this` relate to `super`, and is the `this` seen inside an inherited method the subclass object or the superclass part?

## One object, two keywords Inheritance does not create two objects. When you write `new Dog()` and `Dog extends Animal`, the JVM allocates **one** object whose memory holds the `Animal` fields plus the `Dog` fields. There is a single identity. - **`this`** refers to that one whole object, and its dynamic (runtime) type is the *actual* class you instantiated (`Dog`). - **`super`** is **not** a reference to a different object. It is a compiler directive meaning "resolve this member against my **superclass's** declaration." `super.x` reads the parent's field declaration; `super.m()` calls the parent's method **non-virtually** (without dynamic dispatch). So `this` and `super`, where they refer to state, point at the *same* object; they differ only in **which inherited version of a member** the compiler picks. ## `this` inside an inherited method is the subclass Because Java instance methods are **virtual** (dynamically dispatched on the runtime type of the receiver), the `this` inside a superclass-declared method is the runtime subclass object. Consider: ```java class Animal { void describe() { System.out.println("I am " + name()); } String name() { return "animal"; } } class Dog extends Animal { @Override String name() { return "dog"; } } new Dog().describe(); // prints "I am dog" ``` `describe()` is declared only in `Animal`, but the implicit `this.name()` it calls dispatches on `this`'s runtime type `Dog`, so the override runs. This is the heart of polymorphism: superclass code automatically calls subclass behavior through `this`. ## `super` bypasses dispatch for one call Inside `Dog`, `super.name()` would call `Animal.name()` directly, *not* `Dog.name()`, even though `this` is a `Dog`. `super` is the only standard way to invoke an overridden parent implementation; you cannot get the same effect with a cast (`((Animal) this).name()` still dispatches to `Dog.name()` because casting changes the static type but not the dynamic dispatch target). ## The constructor gotcha Because `this`'s dynamic type is fixed from allocation, calling an **overridable** method from a superclass constructor dispatches to the subclass override *before the subclass constructor body has run*: ```java class Base { Base() { init(); } // calls the overridable method void init() {} } class Sub extends Base { private String val = "set"; @Override void init() { System.out.println(val); } // prints null! } new Sub(); ``` Construction order is: `Base()` runs first (calling `init()`, which dynamically dispatches to `Sub.init()`), but `Sub`'s field initializer (`val = "set"`) has **not** executed yet, so `val` is still `null`. The lesson: never call overridable methods from a constructor. ## `super(...)` and `this(...)` in constructors There are also the constructor-invocation forms: `super(args)` calls a parent constructor, `this(args)` chains to another constructor of the same class; each must be the first statement. These reuse the keywords but are a distinct mechanism (constructor chaining) from member access. ## Identity check `this == this` is trivially true; there is no `super` object to compare, reinforcing that `super` is a resolution mechanism, not an object. Reflexively, the object's `getClass()` inside an inherited method returns the subclass, confirming `this` is the subclass instance. ## Takeaways - One object; `this` = the whole runtime subclass instance. - `super` selects the parent's member version (non-virtual), not a separate object. - Virtual dispatch on `this` makes superclass code invoke subclass overrides — both the power (polymorphism) and the trap (constructor calling overridable methods).