Java Inheritance Interview Questions

Java allows only single inheritance for classes. A class declaration uses extends with exactly one superclass, so a class cannot directly extend more than one parent. The language designers excluded multiple class inheritance to avoid the diamond problem, where a member could be inherited ambiguously from two parents. A class may implement multiple interfaces, but it cannot extend more than one class, so the statement is false.

Java supports single class inheritance only. A class uses the extends keyword to inherit from at most one superclass; attempting to extend two classes is a compile-time error. Multiple inheritance of type is available through implements, but not of classes. The question asks for a single keyword with one defensible answer, so it stays an open short-answer question graded by the keyword extends.

In Java, the super keyword is used to invoke a parent class constructor. The call super(...) must be the first statement in the subclass constructor; if omitted, the compiler inserts a no-arg super() call automatically.

Since Java 5, an overriding method may declare a return type that is a subtype of the return type of the method it overrides, which is called a covariant return type. Before Java 5, the return type had to match exactly. The parameter list must still match exactly for the method to be an override, and changing only the return type without a subtype relationship causes a compile error.

When new Child() runs, Child's constructor first makes an implicit super() call. Parent's field initializers run before Parent's constructor body, so Parent's name is set to Parent, and then the Parent constructor calls describe(). Because Java dispatches instance methods dynamically on the runtime type, the overridden describe() in Child runs. That method reads Child's own name field, which hides Parent's field, but Child's field initializers have not run yet because they execute only after the super constructor returns. So Child's name is still null, and the concatenation prints Child: null.

Individual appends are usually O(1), but an append that triggers a resize copies up to n elements, so a single operation can cost O(n). Because capacity doubles, resizes occur at sizes 1, 2, 4, 8, and so on, so the copies over n appends form a geometric series summing to at most about 2n. Dividing that total O(n) by n appends gives O(1) amortized cost per append. The correct answer therefore names the amortized qualifier together with the constant O(1) bound.

The question tests object construction order in Java inheritance. The superclass constructor executes before the subclass constructor body and before subclass field initializers, so the object exists in a partially constructed state. Because dispatch on an instance method uses the runtime type, a call from the superclass constructor reaches the subclass override, which then sees subclass fields at their default values (0, false, null) rather than their intended initial values. This is why the surprising behavior appears only when the class is subclassed and the method is overridable. The remedy is to make the method final or private, or to avoid calling it during construction, which removes the dynamic dispatch hazard.

Field access in Java is resolved by the declared (compile-time) type, not by dynamic dispatch. b.tag uses the compile-time type Base, so it reads the Base field Base. Method calls are virtual: b.getTag() dispatches to Base.getTag() because Sub does not override it, returning Base.tag which is Base. Output: Base Base.

Must cover dynamic dispatch for instance methods (runtime type) vs compile-time binding for static method hiding (declared type), and the consequence that hidden static methods are not polymorphic. A correct answer contrasts runtime dispatch on the object's actual class for overridden instance methods with compile-time resolution on the reference's declared type for hidden static methods, and notes that calling a hidden static method through a superclass reference runs the superclass version.

The flashcard tests knowledge of the classic pitfall: overridable method calls in constructors run subclass code with uninitialized state.

Java allocates the object and zeroes every instance field (Base's and Sub's) before any constructor runs, so the defaults step is first. The implicit super() call then enters the Base constructor, which runs Base's field initializers before its own body. Inside that body, the call to init() dispatches virtually to Sub.init() because the object is a Sub, but Sub's field initializers have not run yet, so Sub's fields still hold default values. Only after the Base constructor returns does the compiler-generated code run Sub's field initializers, and the Sub constructor body comes last. The key non-obvious point is that the Base constructor body precedes the Sub field initializers.

The variable obj has compile-time type Base but refers to a Derived object. Instance fields are resolved by the declared type of the reference, so obj.tag reads Base.tag, whose value is base-field. Derived declares its own tag field with value sub-field, but that field only hides the superclass field and is not reached through a Base reference. Had the program called obj.resolve() instead, dynamic dispatch would run Derived.resolve() and print sub-field, but the program only prints the field, so the output is base-field.

Line 17 calls apply(value - 10) without a super qualifier. The implicit receiver is this, a FilteredProcessor, so dynamic dispatch selects FilteredProcessor.apply(), the method that is already executing. That method has no base case, so every call makes another call with no end and the stack overflows with a StackOverflowError. The fix is return super.apply(value - 10) + threshold;, which bypasses dynamic dispatch and invokes Processor.apply() directly, so the recursion stops after one level.

The variable b has static type Base but refers to a Derived instance. Derived does not override show(), so b.show() runs Base.show(). Inside that method, id() is a static method, so it is bound at compile time to the id() declared in the enclosing class Base, which returns "Base". (The static String id() in Derived only hides it and is not reached.) The call name() is an instance method, so it is dispatched at runtime on the actual object, a Derived, and Derived.name() returns "Derived". The println therefore prints Base:Derived.

This is false. The class of deterministic context-free languages (DCFLs) is a strict proper subset of the class of all context-free languages (CFLs). Every DCFL is context-free, but not every CFL is deterministic. A classic counterexample is the language of palindromes over a two-letter alphabet, L = { w w^R : w ∈ {a,b}* }, which is generated by the grammar S → aSa | bSb | ε and is therefore context-free, yet cannot be recognized by any deterministic pushdown automaton because determining the midpoint of the input requires unbounded nondeterministic guessing. The two classes also differ in closure properties: DCFLs are closed under complement but not under union, while CFLs are closed under union but not under complement.