Code10x
Inheritancesenior8+ years

`class Base { Base() { init(); } void init() {} }` and `class Derived extends Base { final List<String> items = new ArrayList<>(); @Override void init() { items.add("x"); } }` — constructing a `Derived` throws `NullPointerException` inside `init()`, on a field marked `final` that's initialised right there at its declaration. How, precisely, does an object's class pointer already being `Derived` from the moment of allocation explain this, and why doesn't `final` help?

new Derived() allocates the object with its class pointer set to Derived immediately — before any constructor has run a single line — and every virtual call the JVM makes against that object, from that instant on, dispatches through Derived's vtable, not Base's. Base's constructor calling init() is an ordinary virtual call (invokevirtual), and because the object's class pointer already says Derived, that call lands on Derived.init() — even though Base's constructor is still running and Derived's own constructor, including the field initialiser for items, hasn't executed yet. items is final, but final only means "assigned exactly once"; it says nothing about when that single assignment happens relative to a virtual call landing on code that reads it, so the override runs against a null items regardless of the final keyword.

The lesson behind it →
PreviousA `Plugin` interface adds `default boolean healthy() { return true; }`. A month later, one plugin author reports their health check is being ignored — the platform always treats their plugin as healthy regardless of what their code does. Their class extends a shared `BasePlugin`, which happens to already declare a public `boolean healthy()` method, unrelated to the interface, returning whether the plugin's background thread is alive. No compiler ever mentioned a conflict. Why not, and what actually happens at the call site?Next `interface Parser<T> { T parse(String s); }` and `class IntParser implements Parser<Integer> { public Integer parse(String s) { return Integer.valueOf(s); } }` — `javap -p IntParser` shows *two* `parse` methods in the class file, not one. Neither is dead code. What produced the second one, and which one actually runs when a caller holds a `Parser<Integer>` reference?
More on Inheritance
`class InstrumentedSet<E> extends HashSet<E> { int added = 0; @Override public boolean add(E e) { added++; return super.add(e); } @Override public boolean addAll(Collection<? extends E> c) { added += c.size(); return super.addAll(c); } }` — calling `addAll(List.of("a", "b", "c"))` on a fresh instance leaves `added == 6`, not 3. Where do the extra three come from, and what does it say about extending a class you don't own?