What happens at compile time if a subclass constructor relies on an implicit super() but the parent class has no accessible no-argument constructor?
answer
- Implicit super() targets the parent's NO-ARG constructor
- Default (auto) constructor exists only if a class declares no constructors
- Parent declares any ctor → its implicit no-arg one disappears
- Fix: explicit super(args) or add a no-arg parent ctor
- Even a private no-arg parent ctor is inaccessible → still fails
basics
~20 sIt won't compile. The compiler tries to insert a no-arg super() call, but if the parent has no accessible no-arg constructor, that call is invalid. You must add an explicit super(...) with the right arguments.
solid answer
~50 sIf a subclass constructor doesn't start with an explicit `this(...)` or `super(...)`, the compiler inserts `super()` — a call to the parent's *no-argument* constructor. That only works if such a constructor exists and is accessible. A class gets a default no-arg constructor automatically *only* if it declares no constructors at all. The moment a parent declares any constructor (say, only `Parent(int x)`), it no longer has an implicit no-arg one, so the compiler-inserted `super()` fails to resolve and you get a compile error like 'no suitable constructor / there is no default constructor available'. The fix is to give the subclass constructor an explicit `super(...)` call matching one of the parent's actual constructors (or add a no-arg constructor to the parent). This is a pure compile-time check tied to construction-order rules — every constructor must chain to a valid superclass constructor.
go deeper
Knows you sometimes must write super(...) and that a missing parent constructor causes an error.
Explains that the implicit super() needs an accessible no-arg parent constructor and that declaring any constructor removes the implicit default, with the right fixes.
Adds accessibility nuances (private no-arg fails), varargs edge cases, and frames the compile error as enforcement of the construction-order invariant.
Reasons about API design implications — e.g. deliberately omitting a no-arg constructor to force subclasses to supply required state through super(...), and the trade-offs for frameworks relying on no-arg constructors.
**Terms.** A *no-argument constructor* (no-arg) takes no parameters. A *default constructor* is the implicit, compiler-generated no-arg constructor that Java adds to a class **only when that class declares no constructors of its own**. `super()` is a call to a superclass constructor; `super()` with no arguments targets the parent's no-arg constructor. **The mechanism.** Construction-order rules require every constructor to begin by chaining to a superclass constructor (via explicit `super(...)`, or `this(...)` which eventually reaches a `super(...)`). When you write a constructor whose first statement is neither, the compiler inserts `super()` for you. That inserted call must resolve to a real, accessible no-arg constructor in the direct superclass. **When it breaks.** A class loses its implicit default constructor the instant it declares *any* explicit constructor. So: ``` class Parent { Parent(int x) { } // declares a constructor → no implicit no-arg one exists } class Child extends Parent { Child() { } // compiler inserts super(); but Parent has no no-arg ctor → ERROR } ``` The compiler reports something like *'constructor Parent in class Parent cannot be applied to given types; required: int, found: no arguments'* or *'there is no default constructor available in Parent'*. Accessibility matters too: even a *private* no-arg parent constructor is not accessible from the subclass, so the implicit `super()` still fails. **The fixes.** 1. **Explicit super(...)** in the child: `Child() { super(0); }` — call a real parent constructor. 2. **Add a no-arg constructor to the parent**: `Parent() { }` — restores a target for the implicit `super()`. 3. **Delegate with this(...)**: have the no-arg child constructor call another child constructor that itself calls `super(0)`. **Why it's a feature, not a nuisance.** The rule guarantees that no object is ever created without its superclass portion being properly initialized through a real constructor — there's no way to silently skip parent initialization. The compile error is the language enforcing the construction-order invariant statically. **Related subtlety.** If the parent's only constructor *can* be called with no arguments because it's varargs (`Parent(int... xs)`) or all-defaultable in spirit (Java has no default parameters, so this means varargs), the implicit `super()` may resolve to it. But a plain `Parent(int x)` is not callable with zero arguments, so it fails.
- Does adding any constructor to a class remove its default no-arg constructor?Yes. The compiler generates a default no-arg constructor only if the class declares zero constructors. Declaring any constructor (even a parameterized one) suppresses the implicit default.
- Is this failure detected at compile time or runtime?Compile time. The compiler resolves the implicit super() against the parent's constructors; if no accessible no-arg constructor exists, compilation fails before any code runs.
saying these in an interview costs you the question
- Thinking every class always has a usable no-arg constructor
- Believing the error is a runtime exception (it's a compile error)
- Assuming a private no-arg parent constructor satisfies the implicit super()
- Confusing 'declared a constructor' with 'declared a no-arg constructor' — declaring Parent(int) removes the implicit no-arg one