Core Java & OOP Terminology — Interview Reference

Why this matters in interviews

Senior interviewers use precise OOP and core Java vocabulary to separate engineers who can write working code from those who understand why the language behaves the way it does. Misusing terms like "overriding" vs "overloading," or conflating "abstraction" with "encapsulation," signals surface-level knowledge that does not hold up under follow-up questioning. Mastery of these definitions — including edge cases like type erasure, the PECS rule, and Liskov Substitution violations — demonstrates the depth expected of engineers designing production systems and reviewing others' code.

---

Concept

OOP Fundamentals

---

Interface vs Abstract Class

---

SOLID Principles

---

Generics

---

Immutability & Records

---

Memory & References

---

Exceptions

---

String

---

Key rules / gotchas

• Overloading is resolved at compile time: The declared type of the variable — not the runtime type — determines which overload is called. Passing a Dog reference typed as Animal to an overloaded method picks the Animal overload.
• equals and hashCode contract: If two objects are equals, they must have the same hashCode. Violating this breaks HashMap, HashSet, and any hash-based collection. Records auto-generate a correct implementation; hand-rolled classes frequently get this wrong.
• Type erasure means no generic arrays: new T[10] is a compile error. Use (T[]) new Object[10] with a suppressed warning or pass a Class<T> token to create a typed array via Array.newInstance.
• default method diamond resolution order: The class's own implementation wins first; a more specific interface's default beats a less specific one; if still ambiguous, the compiler requires an explicit override calling InterfaceName.super.method().
• Sealed classes and pattern matching: Every permits-listed subtype must be in the same package or module. switch expressions over a sealed type are exhaustive — the compiler rejects a missing case.
• Phantom reference get() always returns null: Unlike SoftReference.get() and WeakReference.get(), PhantomReference.get() always returns null by design — the reference is for cleanup notification only.
• try-with-resources and suppressed exceptions: If both the try body and the implicit close() call throw, the close() exception is suppressed (attached to the primary exception via addSuppressed), not silently swallowed.
• LSP and behavioral subtyping: LSP is not just about method signatures — it requires that preconditions are not strengthened and postconditions are not weakened in the subtype. A Square that silently changes both dimensions when only one is set strengthens the postcondition and violates LSP.
• String == pitfall: "a" + "b" == "ab" is true (compile-time constant folding), but new String("a") + "b" == "ab" is false. Always use equals() unless you explicitly interned the strings.

---

Code example

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

/**
 * Demonstrates: dynamic dispatch via vtable, PECS with generics,
 * immutable class pattern, try-with-resources, and Java records.
 *
 * All senior-level Java interview concepts in one runnable class.
 */
public class JavaLabRunner {

    // ─── 1. Dynamic dispatch (vtable in action) ───────────────────────────────

    abstract static class Shape {
        abstract double area();

        @Override
        public String toString() {
            // covariant return type not shown here, but overriding toString() is
            return getClass().getSimpleName() + " area=" + String.format("%.2f", area());
        }
    }

    static class Circle extends Shape {
        private final double radius;
        Circle(double radius) { this.radius = radius; }

        @Override
        double area() { return Math.PI * radius * radius; }  // runtime dispatch
    }

    static class Rectangle extends Shape {
        private final double w, h;
        Rectangle(double w, double h) { this.w = w; this.h = h; }

        @Override
        double area() { return w * h; }  // runtime dispatch
    }

    // ─── 2. Immutable class pattern ───────────────────────────────────────────

    static final class Money {
        private final long cents;      // final field
        private final String currency; // String itself is immutable — no copy needed

        Money(long cents, String currency) {
            if (cents < 0) throw new IllegalArgumentException("Negative money");
            this.cents = cents;
            this.currency = currency;
        }

        long cents()       { return cents; }
        String currency()  { return currency; }

        Money add(Money other) {
            if (!currency.equals(other.currency))
                throw new IllegalArgumentException("Currency mismatch");
            return new Money(cents + other.cents, currency); // returns new instance
        }

        @Override public String toString() {
            return currency + " " + String.format("%.2f", cents / 100.0);
        }
    }

    // ─── 3. Java Record (Java 16+) ────────────────────────────────────────────
    // Auto-generates: canonical constructor, private final fields,
    // accessors (x(), y()), equals(), hashCode(), toString().
    record Point(int x, int y) {
        // Compact canonical constructor — validation without re-assigning fields
        Point {
            if (x < 0 || y < 0) throw new IllegalArgumentException("Negative coordinate");
        }
    }

    // ─── 4. AutoCloseable for try-with-resources ──────────────────────────────

    static class ManagedResource implements AutoCloseable {
        private final String name;
        ManagedResource(String name) {
            this.name = name;
            System.out.println("  [open]  " + name);
        }

        void process() {
            System.out.println("  [use]   " + name);
        }

        @Override
        public void close() {
            // In real code this releases DB connections, file handles, etc.
            System.out.println("  [close] " + name + "  ← guaranteed by try-with-resources");
        }
    }

    // ─── 5. PECS helper methods ───────────────────────────────────────────────

    /** Producer Extends — reads Shapes from src, computes total area. */
    static double totalArea(List<? extends Shape> src) {
        // src is a PRODUCER of Shape — we only read from it
        double sum = 0;
        for (Shape s : src) sum += s.area();
        return sum;
    }

    /** Consumer Super — writes Shapes into dest. */
    static void addDefaultShapes(List<? super Shape> dest) {
        // dest is a CONSUMER of Shape — we only write into it
        dest.add(new Circle(1));
        dest.add(new Rectangle(2, 3));
    }

    // ─── main ─────────────────────────────────────────────────────────────────

    public static void main(String[] args) {

        // 1. Dynamic dispatch — reference type is Shape, runtime type varies
        System.out.println("=== Dynamic Dispatch (vtable) ===");
        List<Shape> shapes = new ArrayList<>();
        shapes.add(new Circle(5));
        shapes.add(new Rectangle(3, 4));
        for (Shape s : shapes) {
            // The JVM looks up s's vtable to find the correct area() override
            System.out.println("  " + s);  // calls overridden toString() + area()
        }

        // 2. PECS — Producer Extends, Consumer Super
        System.out.println("\n=== PECS Rule ===");
        List<Circle>    circles    = List.of(new Circle(2), new Circle(3));
        List<Rectangle> rectangles = List.of(new Rectangle(1, 2));

        // totalArea accepts List<Circle> and List<Rectangle> because ? extends Shape
        System.out.printf("  circles total area    = %.2f%n", totalArea(circles));
        System.out.printf("  rectangles total area = %.2f%n", totalArea(rectangles));

        // addDefaultShapes accepts List<Shape> or List<Object> because ? super Shape
        List<Shape> bucket = new ArrayList<>();
        addDefaultShapes(bucket);
        System.out.printf("  bucket total area     = %.2f%n", totalArea(bucket));

        // 3. Immutable class
        System.out.println("\n=== Immutable Class ===");
        Money price    = new Money(1999, "USD");
        Money tax      = new Money(160,  "USD");
        Money total    = price.add(tax);     // returns new Money — originals unchanged
        System.out.println("  price=" + price + "  tax=" + tax + "  total=" + total);

        // 4. Record
        System.out.println("\n=== Record ===");
        Point p1 = new Point(3, 4);
        Point p2 = new Point(3, 4);
        System.out.println("  p1=" + p1);                     // auto toString
        System.out.println("  p1.equals(p2) = " + p1.equals(p2)); // auto equals
        System.out.println("  p1 == p2      = " + (p1 == p2));    // false — different instances

        // 5. try-with-resources — close() called automatically, even on exception
        System.out.println("\n=== try-with-resources ===");
        try (ManagedResource r = new ManagedResource("DBConnection")) {
            r.process();
            // close() is guaranteed to run after this block exits
        }
        // No explicit finally needed — r.close() was already called above

        // Multi-catch example (compile-time, no actual exception thrown here)
        System.out.println("\n=== Multi-catch (structure) ===");
        try {
            String s = null;
            int len = s.length();          // throws NullPointerException
            System.out.println(len);
        } catch (NullPointerException | IllegalArgumentException e) {
            System.out.println("  caught: " + e.getClass().getSimpleName() + " — " + e.getMessage());
        }

        System.out.println("\nAll demos complete.");
    }
}

---

Interview questions you should be able to answer

• Q: What is the virtual method table (vtable) and how does the JVM use it to implement dynamic dispatch?

  Every class in the JVM has a vtable — a table of pointers to the most-derived implementation of each virtual method. When you call a method on a reference, the JVM dereferences the object's header to find its class, then looks up the method in that class's vtable. This means the runtime type always wins, even though the reference is declared as a supertype. Static methods, private methods, and final methods bypass the vtable and are resolved at compile time (static binding), which is why they cannot be meaningfully overridden.

• Q: What are the practical consequences of type erasure for a senior engineer writing generic library code?

  Because generic type parameters are erased to their bound (Object by default) at runtime, you cannot use instanceof with a parameterized type, create generic arrays (new T[]), overload on generic types alone, or catch a generic exception type. You also cannot determine at runtime whether a List holds String or Integer — both erase to List. Library authors work around this by passing explicit Class<T> tokens (type tokens), using @SuppressWarnings("unchecked") with documented reasoning, and marking safe varargs methods with @SafeVarargs.

• Q: Explain the PECS rule and show how it applies to Collections.copy.

  PECS stands for Producer Extends, Consumer Super. A structure you only read from is a producer — declare it ? extends T (covariant upper-bounded wildcard). A structure you only write into is a consumer — declare it ? super T (contravariant lower-bounded wildcard). Collections.copy(List<? super T> dest, List<? extends T> src) follows PECS exactly: src produces T values (you read them), so it is ? extends T; dest consumes T values (you write into it), so it is ? super T. This signature is maximally flexible — src can be a List<Integer> and dest can be a List<Number> when T is Integer.

• Q: Why is String immutable in Java, and what are the three concrete benefits immutability provides?

  First, string pool sharing: because a String can never change, the JVM safely hands out the same object to every reference to the same literal, saving heap memory. Second, hashCode caching: String.hashCode() is computed once and cached in a private field — immutability guarantees the cached value is always valid, making String keys in HashMap very efficient. Third, security: many security-sensitive APIs (file paths, class names, network hostnames) accept String. If String were mutable, a thread could pass a validated string to a security check and then mutate it before the actual operation, creating a TOCTOU vulnerability.

• Q: Give a concrete example of a Liskov Substitution Principle violation and explain why it is dangerous.

  The classic example is Square extends Rectangle. A Rectangle has independent width and height setters. A Square must keep both equal, so its setWidth(w) also sets height to w. Code that does rect.setWidth(5); rect.setHeight(3); assert rect.area() == 15; passes for a Rectangle but fails for a Square — the Square silently changed the height during setWidth. This is dangerous because callers that receive a Rectangle reference have a reasonable expectation of its postconditions, and the subtype breaks them. The fix is not to use inheritance here — Square and Rectangle should be separate types, or Rectangle should be immutable.

• Q: How does Java resolve the diamond problem when two interfaces provide a default method with the same signature?

  Java applies a priority chain. First, a concrete method in the implementing class (or any of its superclasses) always wins over any interface default. Second, if no class implementation exists, the more specific interface wins — if B extends A and both define default greet(), then a class implementing B gets B's version. Third, if neither interface is more specific (a true diamond — two unrelated interfaces each with default greet()), the compiler reports an error and requires the implementing class to explicitly override the method, calling the desired interface's version via InterfaceName.super.greet(). This is fundamentally different from C++ multiple inheritance of data members, because Java interfaces carry no mutable state.

---

Further reading

• Effective Java, 3rd ed., Joshua Bloch — Items 15–25 (classes and interfaces), Items 28–33 (generics), Items 76–77 (exceptions)
• JEP 359 (Records), JEP 409 (Sealed Classes), JEP 305 (Pattern Matching for instanceof) — openjdk.org/jeps
• Java Language Specification §15.12.4.4 — virtual method invocation (vtable semantics)
• Oracle Generics Tutorial — Wildcards and Subtyping, Type Erasure sections — docs.oracle.com/javase/tutorial/java/generics
• "Understanding Java's Memory Model" — Heinz Kabutz, JavaSpecialists Newsletter — javaspecialists.eu
• "SOLID Principles in Java" — Baeldung guide with annotated code examples — baeldung.com/solid-principles