Classes & objects: interview questions & scenarios

Model answer

A class is a type: it declares fields and methods, and it's loaded once per class loader, with its metadata in Metaspace and one java.lang.Class object representing it. An object is one instance of that class on the heap: a header plus its own copy of the instance fields. Method code is never copied per object.

Variables hold references, not objects. So a == b asks "do these point at the same object?", never "do they have the same contents?". Contents are what equals compares, if the class overrides it.

Order a = new Order(7, "alice");
Order b = new Order(7, "alice");
System.out.println(a == b);        // false: two objects
System.out.println(a.equals(b));   // false unless Order overrides equals

Model answer

If a class declares no constructors, javac adds a default constructor: no parameters, same access as the class, body that only calls super(). The moment you declare any constructor, even one with parameters, the default one is no longer generated.

class Customer {
    private final String email;
    Customer(String email) { this.email = email; }
}
new Customer();   // compile error: constructor Customer in class Customer cannot be applied to given types

Model answer

A constructor can be public, protected, package-private or private. It can't be final, static, abstract or synchronized, because none of those make sense for something that isn't inherited, needs an instance, and always has a body. It has no return type; if you write void Order(), that's a regular method that happens to share the class name.

A private constructor is common: utility classes (private Util() {}), singletons, and classes that force callers through a static factory such as Money.of(...).

Model answer

A concrete class is one you can instantiate with new: every method has an implementation, inherited or its own. An abstract class can't be instantiated directly, and an interface never can.

An abstract class can and often does have constructors. They run when a concrete subclass is created, through super(...), to initialise the abstract parent's fields. Interfaces have no constructors and no instance fields.

abstract class Notification {
    protected final String recipient;
    protected Notification(String recipient) { this.recipient = recipient; }
    abstract void send();
}
class EmailNotification extends Notification {
    EmailNotification(String to) { super(to); }
    @Override void send() { System.out.println("email to " + recipient); }
}

Model answer

this is a reference to the current object; you use it to reach fields shadowed by parameters, pass yourself to other code, or return yourself for chaining. this(...) is a call to another constructor of the same class, used to keep construction logic in one place.

this(...) and super(...) must each be the first statement of a constructor in Java 21, so a constructor can use one or the other, never both. The constructor at the end of a this(...) chain is the one that calls super, and field initialisers run only there.

Model answer

class Base {
    static { System.out.println("Base static"); }
    { System.out.println("Base block"); }
    Base() { System.out.println("Base ctor"); }
}
class Card extends Base {
    static { System.out.println("Card static"); }
    private final String label = log("Card field");
    { System.out.println("Card block"); }
    Card() { System.out.println("Card ctor"); }
    static String log(String s) { System.out.println(s); return s; }
}

new Card();
new Card();

The first new Card() prints Base static, Card static, Base block, Base ctor, Card field, Card block, Card ctor. The second prints only the last five: static initialisation happens once per class. The diagram shows the order.

Fig. 1

Order of execution for two new Card() calls: class initialisation runs Base static then Card static once; each instance then runs Base's instance block and constructor, then Card's field initialiser, instance block and constructor

Rules behind it: the parent class initialises before the child; for each instance, super() runs first, then that class's field initialisers and instance blocks in textual order, then the rest of the constructor body.

Model answer

• new, plus static factories, builders and constructor references (Order::new), which all call new.
• Reflection: getDeclaredConstructor(...).newInstance(...) or a MethodHandle from findConstructor.
• clone().
• Deserialization (Java serialization).

The first two groups run a constructor. clone() copies fields from an existing object without any constructor. Java deserialization runs only the no-arg constructor of the first non-serializable superclass, so the serializable class's own constructor and its validation are skipped. Records are the exception: they're deserialized through their canonical constructor.

Model answer

In bytecode it's new, dup, push arguments, invokespecial Order.<init>, store. In HotSpot that becomes six steps:

1. Class check: resolve Order; load, link and initialise it on first use.
2. Allocate: bump the pointer in this thread's TLAB by the object size, no lock.
3. Zero: every field gets its default (0, false, null).
4. Header: write the mark word and the class pointer.
5. Constructor chain: <init> runs, calling super() up to Object, then initialisers and body on the way down.
6. Publish: the reference is stored in your variable.

Model answer

private is visible only inside the top-level class that declares it (including its nested classes). Package-private (no modifier) adds the rest of the package. protected adds subclasses in other packages, with a catch. public is visible everywhere the module exports the package. The grid below shows who can see what.

Fig. 1

Access grid: private is visible only within the same class; package-private adds the same package; protected adds subclasses in other packages but only through their own type; public is visible everywhere

The catch: a subclass in another package can access a protected member only through references of its own type (or a subtype), not through a plain parent reference.

package com.shop.base;
public class Account { protected long balance; }

package com.shop.app;
class Savings extends com.shop.base.Account {
    void move(com.shop.base.Account other, Savings mine) {
        long a = this.balance;    // ok
        long b = mine.balance;    // ok
        long c = other.balance;   // compile error: balance has protected access
    }
}

A top-level class can only be public or package-private. private and protected are allowed on nested classes.

Model answer

A static factory helps when a name explains intent (Money.ofCents(500) versus Money.ofRupees(5)), when you want to cache or reuse instances (Integer.valueOf, List.of()), when you want to return a subtype or hide the implementation class, or when the object must be fully built before a side effect such as registration.

A builder helps when there are many parameters, especially optional ones, or several of the same type that are easy to swap. It names each argument and validates once in build().

I default to constructors for small, always-valid classes; a factory when naming, caching or post-construction steps matter; and a builder past about four or five parameters.

Model answer

Adding any constructor removed the compiler-generated no-arg constructor. JPA providers instantiate entities reflectively through a no-arg constructor (the spec requires it to be public or protected), then fill fields. Jackson does the same by default unless you annotate a constructor with @JsonCreator or compile with -parameters and its parameter-names module.

The fix is to declare the no-arg constructor explicitly, protected so application code still uses the meaningful one:

@Entity
public class Shipment {
    @Id private Long id;
    private String trackingCode;

    protected Shipment() {}                       // for JPA
    public Shipment(String trackingCode) { this.trackingCode = trackingCode; }
}

Model answer

class Notifier {
    Notifier() { send(); }
    void send() { System.out.println("base send"); }
}
class SmsNotifier extends Notifier {
    private String phone = "+91-98000-00000";
    private int retries = 3;
    @Override void send() { System.out.println("sms to " + phone + ", retries " + retries); }
}

new SmsNotifier();   // prints: sms to null, retries 0

Notifier() runs first, as super() inside the SmsNotifier constructor, and calls send() through virtual dispatch, which picks the override. At that moment SmsNotifier's field initialisers haven't run yet, so the fields still hold their zeroed defaults.

Model answer

The constructor published this before it finished. Something like bus.register(this) runs, then the fields are assigned. If the bus delivers an event on another thread in that window, onEvent reads the field while it's still null. Tests miss it because test buses are usually single-threaded.

Moving register(this) to the last line narrows the window but isn't a real fix: the Java Memory Model guarantees other threads see correct final field values only if this doesn't escape during construction (JLS 17.5). The fix is to separate building from publishing:

public static PriceListener start(EventBus bus, String symbol) {
    PriceListener l = new PriceListener(symbol);   // private ctor, fields only
    bus.register(l);                               // publish the finished object
    return l;
}

Model answer

The cache uses Java serialization, and deserialization doesn't run Order's constructor. It allocates the object, runs the no-arg constructor of the first non-serializable superclass (Object), then writes field values from the bytes. Old cache entries written before the validation existed, or a tampered stream, produce an Order that skipped the check.

Fixes, in order of preference: switch the cached type to a record (deserialized through its canonical constructor) or to JSON bound through a constructor; or add a readObject that re-validates and throws InvalidObjectException; or use the serialization proxy pattern with readResolve.

Model answer

Each handler registered an anonymous inner class listener with a long-lived event bus. An anonymous class created in an instance method holds a hidden reference to its enclosing instance (this$0) whenever it uses outer state, so the bus keeps the listener alive, the listener keeps the handler alive, and the handler keeps its whole request graph alive. Nobody ever unregisters.

Fixes: unregister when the handler is done (try/finally or a close hook), register a static nested class or a lambda that captures only the data it needs, or use a bus that holds listeners weakly.

Model answer

Allocation itself is cheap: a TLAB pointer bump costs a few nanoseconds, and young-generation GC cost scales with the objects that survive, not the ones that die. Pooling small objects usually makes things worse: pooled objects live long, get promoted to the old generation, need resetting, and add contention.

What I'd actually check: GC logs or JFR for young-pause frequency and promotion rate; whether objects survive longer than they should (held in a batch or cache); and whether the JIT already scalar-replaces them. Then cut allocation at the source: primitives instead of boxed values, presized collections, reusing a StringBuilder inside a method.