Basics

Entry Point and Syntax

Java forces everything into a class. There are no free functions. The entry point is a static method called main — the JVM looks for it by name:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

Every word in the signature has a purpose:

Quick mapping from Python and C++:

// Variables — declare type like C++
int count = 10;
double pi = 3.14159;
String name = "Alice";     // String is a class, not a primitive
boolean done = false;      // not 'bool' (C++) or True/False (Python)

// Printing
System.out.println("Count: " + count);

// Arrays — fixed size, .length is a field (no parentheses)
int[] scores = {90, 85, 92};
System.out.println(scores.length);  // 3 — NOT .length() or len()

// Enhanced for — like Python's "for x in list"
for (int s : scores) {
    System.out.println(s);
}

Size inconsistency: Arrays use .length (field). Strings use .length() (method). Collections use .size() (method). This is a well-known Java wart.

The Dual Type System: Primitives and Wrappers

Java has 8 primitive types that live on the stack (like C++ value types), and corresponding wrapper classes that live on the heap:

Why wrappers exist: Java generics only work with objects, not primitives. You cannot write ArrayList<int> — you must write ArrayList<Integer>.

Autoboxing is the automatic conversion between primitive and wrapper:

ArrayList<Integer> numbers = new ArrayList<>();
numbers.add(42);              // autoboxing: int → Integer
int first = numbers.get(0);   // unboxing: Integer → int

Autoboxing Traps

Trap 1 — Null unboxing causes NullPointerException:

Integer count = null;
int n = count;    // NullPointerException! Can't unbox null.

Trap 2 — Boxing in loops is slow:

// BAD — creates a new Integer object on every iteration
Integer sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;  // unbox sum, add i, box result — every iteration!
}

// GOOD — use primitive type for accumulation
int sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;  // pure arithmetic, no boxing
}

The Identity Trap: == vs .equals()

⚠ False Friend: In Python, == compares values. In Java, == on objects compares identity (are these the exact same object in memory?), not value equality.

String c = new String("hello");
String d = new String("hello");
System.out.println(c == d);       // false — different objects in memory
System.out.println(c.equals(d));  // true  — same characters

String literals appear to work with == because Java interns them into a shared pool:

String a = "hello";
String b = "hello";
System.out.println(a == b);  // true — but only because both point to the interned literal!

Do not rely on this. Always use .equals() for string comparison.

The Integer cache trap: Java caches Integer objects for values −128 to 127, making == accidentally work for small numbers:

Integer x = 127;
Integer y = 127;
System.out.println(x == y);     // true (cached — same object)

Integer p = 128;
Integer q = 128;
System.out.println(p == q);     // false (not cached — different objects)
System.out.println(p.equals(q)); // true (always use .equals())

The golden rule:

• Use == for primitives (int, double, boolean, char)
• Use .equals() for everything else (objects, strings, wrapper types)

Object-Oriented Programming

Classes and Encapsulation

A Java class bundles private fields with public methods that control access. Unlike Python (where self.balance is always accessible) and C++ (where you control access at the class level), Java enforces encapsulation at compile time.

public class BankAccount {
    private String owner;    // private — only accessible within this class
    private double balance;

    public BankAccount(String owner, double initialBalance) {
        this.owner = owner;          // 'this' disambiguates field from parameter
        this.balance = initialBalance;
    }

    public void deposit(double amount) {
        if (amount > 0) {            // validation — callers can't bypass this
            balance += amount;
        }
    }

    public boolean withdraw(double amount) {
        if (amount > 0 && balance >= amount) {
            balance -= amount;
            return true;
        }
        return false;               // returns false instead of allowing overdraft
    }

    public double getBalance() { return balance; }
    public String getOwner()   { return owner; }

    // Called automatically by System.out.println(account) — like Python's __str__
    public String toString() {
        return "BankAccount[owner=" + owner + ", balance=" + balance + "]";
    }
}

Access Modifiers

Java has four access levels. The default (no keyword) is different from C++:

⚠ False Friend from C++: In C++, the default access in a class is private. In Java, the default is package-private — accessible to any class in the same package. Always be explicit.

In UML class diagrams: - means private, + means public, # means protected, ~ means package-private.

Information Hiding

Encapsulation (using private fields) is a mechanism. Information hiding is a design principle.

A module hides its secrets — design decisions that are likely to change. When a secret is properly hidden, changing that decision modifies exactly one class. When a secret leaks, a single change cascades across many classes.

The Getter/Setter Fallacy

Fields can be private and yet still leak design decisions:

// Fully encapsulated — but leaking the "ISBN is an int" decision
class Book {
    private int isbn;
    public int getIsbn() { return isbn; }
    public void setIsbn(int isbn) { this.isbn = isbn; }
}

When the spec changes to support international ISBNs with hyphens (String), every caller of getIsbn() breaks. The module is encapsulated but hides nothing.

Better design — expose behavior, not data:

// Hides the representation; callers depend on behavior only
class GradeReport {
    private ArrayList<Integer> scores;  // hidden

    public String getLetterGrade(int score) { ... }  // hides the grading policy
    public double getAverage()             { ... }  // hides the data representation
    public String formatReport()           { ... }  // hides the output format
}

Test for information hiding: For each design decision, ask: “If this changes, how many classes must I edit?” If the answer is more than one, the secret has leaked.

Interfaces: Design by Contract

An interface defines what a class can do, without specifying how. Java’s philosophy:

Program to an interface, not an implementation.

// Defining an interface — method signatures only
public interface Shape {
    double getArea();
    double getPerimeter();
    String describe();
}

// Implementing an interface — must provide ALL methods
public class Circle implements Shape {
    private double radius;

    public Circle(double radius) { this.radius = radius; }

    public double getArea()      { return Math.PI * radius * radius; }
    public double getPerimeter() { return 2 * Math.PI * radius; }
    public String describe()     { return "Circle(r=" + radius + ")"; }
}

Declare variables as the interface type so you can swap implementations without changing calling code:

Shape s = new Circle(5.0);    // interface type on the left
Shape r = new Rectangle(3, 4);
// s and r can be used interchangeably anywhere Shape is expected

Compared to C++ and Python:

Inheritance and Polymorphism

Java supports single class inheritance with abstract classes for sharing both state and behavior:

// Abstract class — cannot be instantiated, may have concrete fields and methods
public abstract class Vehicle {
    private String make;
    private int year;

    public Vehicle(String make, int year) {  // abstract classes have constructors
        this.make = make;
        this.year = year;
    }

    public String getMake() { return make; }
    public int getYear()    { return year; }

    // Subclasses MUST implement these
    public abstract String describe();
    public abstract String startEngine();
}

public class Car extends Vehicle {
    private int numDoors;

    public Car(String make, int year, int numDoors) {
        super(make, year);  // MUST call parent constructor first — like C++ initializer lists
        this.numDoors = numDoors;
    }

    @Override  // optional but recommended — compiler verifies you're actually overriding
    public String describe() {
        return getYear() + " " + getMake() + " Car (" + numDoors + " doors)";
    }

    @Override
    public String startEngine() { return "Vroom!"; }
}

Polymorphism — a parent reference can point to any subclass:

Vehicle[] fleet = {
    new Car("Toyota", 2024, 4),
    new Motorcycle("Harley", 2023, true),
};

for (Vehicle v : fleet) {
    System.out.println(v.describe());  // calls Car.describe() or Motorcycle.describe()
    //                                    based on the actual runtime type — dynamic dispatch
}

Key differences from C++:

• Java methods are virtual by default — no virtual keyword needed
• @Override annotation is optional but the compiler validates it catches typos
• super(args) must be the first statement in a constructor (C++ uses initializer lists)

When to use interface vs abstract class:

Generics

Generics: Not C++ Templates

Java generics look like C++ templates but work completely differently:

// A generic class — T is a type parameter
public class Box<T> {
    private T item;

    public Box(T item) { this.item = item; }
    public T getItem()  { return item; }
}

// The compiler ensures type safety — no casts needed
Box<String> nameBox = new Box<>("Alice");
String name = nameBox.getItem();  // compiler knows it's String

Box<Integer> numBox = new Box<>(42);
int num = numBox.getItem();       // unboxing Integer → int

Generic methods declare their own type parameters:

// <X, Y> before the return type — method's own type parameters
public static <X, Y> Pair<Y, X> swap(Pair<X, Y> pair) {
    return new Pair<>(pair.getSecond(), pair.getFirst());
}

Bounded type parameters — restrict what types are allowed:

// T must implement Comparable<T> — like C++20 concepts
public static <T extends Comparable<T>> T findMax(T a, T b) {
    return a.compareTo(b) >= 0 ? a : b;
}

Type Erasure

When Java 5 added generics (2004), billions of lines of pre-generics code already existed. To maintain binary compatibility, generic types are erased after compilation:

// What you write:
List<String> names = new ArrayList<>();
String first = names.get(0);

// What the compiler generates (roughly):
List names = new ArrayList();
String first = (String) names.get(0);  // cast inserted by compiler

Consequences:

• ArrayList<int> is illegal — use ArrayList<Integer> instead
• new T() is illegal — type is unknown at runtime
• if (list instanceof List<String>) is illegal — generic type is erased

Collections Framework

Choosing the Right Collection

Java Collections are organized by interfaces. Declare variables as the interface type:

@startuml
interface Collection
interface List
interface Set
interface Map
class ArrayList <>
class LinkedList <>
class HashSet <<unordered, fast>>
class TreeSet <>
class HashMap <<unordered, fast>>
class TreeMap <>

List --|> Collection
Set --|> Collection
ArrayList ..|> List
LinkedList ..|> List
HashSet ..|> Set
TreeSet ..|> Set
HashMap ..|> Map
TreeMap ..|> Map
@enduml
</code></pre>

| Need | Interface | Implementation | Python Equivalent |
|------|-----------|---------------|-------------------|
| Ordered sequence, index access | `List` | `ArrayList` | `list` |
| Unique elements, fast lookup | `Set` | `HashSet` | `set` |
| Key-value pairs | `Map<K,V>` | `HashMap<K,V>` | `dict` |
| Sorted unique elements | `Set` | `TreeSet` | `sorted(set(...))` |
| Sorted key-value pairs | `Map<K,V>` | `TreeMap<K,V>` | sorted `dict` |

**C++ mapping:** `vector` → `ArrayList`, `unordered_map` → `HashMap`, `map` → `TreeMap`, `unordered_set` → `HashSet`.

## Common Operations

```java
// List — like Python list or C++ vector
List names = new ArrayList<>();
names.add("Alice");              // append
names.add(0, "Bob");             // insert at index
String first = names.get(0);    // index access
names.size();                   // NOT .length — that's arrays!

// Map — like Python dict or C++ unordered_map
Map<String, Integer> scores = new HashMap<>();
scores.put("Alice", 95);        // insert or update
scores.get("Alice");            // lookup — returns null if missing!
scores.containsKey("Alice");    // check existence — always do this before get()
scores.getOrDefault("Bob", 0);  // safe lookup with a default

// Set — like Python set or C++ unordered_set
Set unique = new HashSet<>();
unique.add("Alice");
unique.add("Alice");            // silently ignored — already present
unique.contains("Alice");       // true
unique.size();                  // 1

// Iterating a Map
for (Map.Entry<String, Integer> entry : scores.entrySet()) {
    System.out.println(entry.getKey() + ": " + entry.getValue());
}
```

> **⚠ NullPointerException trap:** `HashMap.get(key)` returns `null` for missing keys. If you assign the result directly to a primitive (`int val = map.get("missing")`), auto-unboxing `null` throws `NullPointerException`. Always use `containsKey()` first, or `getOrDefault()`.

**Declare as the interface type** — this lets you swap implementations without changing callers:

```java
// ✓ Interface type — can swap to TreeMap later with no other changes
Map<String, Integer> scores = new HashMap<>();

// ✗ Concrete type — callers break if you switch to TreeMap
HashMap<String, Integer> scores = new HashMap<>();
```

# Exception Handling

## Checked vs Unchecked Exceptions

Java is unique in dividing exceptions into two categories:

| Category | Extends | Compiler enforcement | Use for |
|----------|---------|---------------------|---------|
| **Checked** | `Exception` (but not `RuntimeException`) | Must catch or declare `throws` | Recoverable external failures (file not found, network error) |
| **Unchecked** | `RuntimeException` | No enforcement | Programming errors (null pointer, bad index, bad argument) |
| **Error** | `Error` | No enforcement | JVM failures — never catch these |

```java
// Checked: compiler forces handling
public String readFile(String path) throws IOException {
    // ... might throw IOException
}

// Callers MUST handle it — the compiler won't let them ignore it
try {
    String content = readFile("data.txt");
} catch (IOException e) {
    System.err.println("File error: " + e.getMessage());
}

// Unchecked: no compiler enforcement (like Python/C++)
public int divide(int a, int b) {
    return a / b;  // might throw ArithmeticException — compiler doesn't require handling
}
```

**Compared to Python and C++:**

| Aspect | Python | C++ | Java |
|---|---|---|---|
| Philosophy | EAFP — catch freely | Exceptions are expensive; prefer error codes | Checked exceptions = compiler-enforced contract |
| Enforcement | None — errors discovered at runtime | `noexcept` exists but rarely enforced | Compiler rejects unhandled checked exceptions |

## Custom Exceptions

```java
// Checked custom exception — extends Exception
public class InsufficientFundsException extends Exception {
    private double deficit;

    public InsufficientFundsException(double deficit) {
        super("Insufficient funds: need " + deficit + " more");  // like Python's super().__init__
        this.deficit = deficit;
    }

    public double getDeficit() { return deficit; }
}

// Usage
public boolean withdraw(double amount) throws InsufficientFundsException {
    if (amount > balance) {
        throw new InsufficientFundsException(amount - balance);
    }
    balance -= amount;
    return true;
}
```

**Multiple catch blocks** — catch specific exceptions before general ones:

```java
try {
    String content = readFile("data.txt");
    int value = Integer.parseInt(content.trim());
} catch (FileNotFoundException e) {
    System.err.println("File missing: " + e.getMessage());
} catch (IOException e) {
    System.err.println("Read error: " + e.getMessage());
} catch (NumberFormatException e) {
    System.err.println("Not a number: " + e.getMessage());
} finally {
    // runs whether or not an exception was thrown — use for cleanup
    closeResources();
}
```

# Design Principles

## Top 10 Java Best Practices

### 1. Always use `.equals()` for object comparison, never `==`

```java
// ✓ Always correct
if (name.equals("Alice")) { ... }
if (a.equals(b)) { ... }

// ✗ Compares identity — will fail with new String("Alice")
if (name == "Alice") { ... }
```

The same applies to all wrapper types (`Integer`, `Double`, etc.) and any object.

### 2. Make fields `private`; validate in setters and constructors

```java
// ✓ Encapsulation with validation — callers can't bypass the contract
public void deposit(double amount) {
    if (amount > 0) {
        balance += amount;
    }
}

// ✗ Public fields let callers bypass all validation
public double balance;
```

### 3. Use primitives for accumulation, wrappers only when required

```java
// ✓ Primitive — no boxing overhead
int sum = 0;
for (int score : scores) { sum += score; }

// ✗ Boxing every iteration — slower and allocates garbage
Integer sum = 0;
for (int score : scores) { sum += score; }  // boxes sum on every iteration
```

Use wrapper types only when required: generics (`List`), nullable values, or calling methods (`.compareTo()`).

### 4. Declare variables as interface types, not concrete classes

```java
// ✓ Interface type — easy to swap implementation
List names = new ArrayList<>();
Map<String, Integer> scores = new HashMap<>();

// ✗ Concrete type — caller breaks if you switch to LinkedList or TreeMap
ArrayList names = new ArrayList<>();
```

### 5. Program to the interface, not the implementation

Design method parameters and return types as interfaces. This enables polymorphism and makes code easier to test:

```java
// ✓ Accepts any List — works with ArrayList, LinkedList, etc.
public double average(List scores) { ... }

// ✗ Unnecessarily restricts callers to ArrayList
public double average(ArrayList scores) { ... }
```

### 6. Use `@Override` when overriding methods

`@Override` is optional, but it tells the compiler to verify that you're actually overriding a parent method. Without it, a typo in the method name silently creates a new method instead of overriding:

```java
@Override
public String toString() { ... }   // compiler error if toString is misspelled
```

### 7. Handle checked exceptions at the right level

Don't catch exceptions before you can actually handle them. If a method can't recover from a failure, let it propagate:

```java
// ✓ Handle it where you can do something useful
try {
    loadConfig("config.txt");
} catch (IOException e) {
    loadDefaults();  // meaningful recovery
}

// ✗ Swallowing exceptions hides bugs — never do this
try {
    loadConfig("config.txt");
} catch (IOException e) {
    // empty — the problem disappears silently
}
```

### 8. Use `getOrDefault()` instead of null checks on Maps

```java
// ✓ Safe and concise
int count = scores.getOrDefault("Alice", 0);

// ✗ Verbose null check
int count = 0;
if (scores.containsKey("Alice")) {
    count = scores.get("Alice");
}
```

### 9. Hide design decisions behind stable interfaces (Parnas 1972)

Each class should hide a **secret** — a design decision likely to change. When something changes, exactly one class changes:

```java
// ✓ Secret (grading policy) is hidden — change thresholds by editing one method
public String getLetterGrade(int score) {
    if (score >= 90) return "A";
    if (score >= 80) return "B";
    ...
}

// ✗ Grading policy leaks into calling code — changes require editing many places
if (score >= 90) letter = "A";  // in main, not in GradeReport
```

### 10. Choose the right collection for the job

| If you need… | Use |
|---|---|
| Ordered sequence with index access | `ArrayList` |
| Fast membership testing | `HashSet` |
| Key-to-value mapping with fast lookup | `HashMap<K,V>` |
| Sorted elements | `TreeSet` or `TreeMap<K,V>` |
| Deduplication | `HashSet` — add freely, duplicates are ignored |











  

    

      
Java — What Does This Code Do?
      
      
        
      
      
    
    
You are shown Java code. Go beyond naming what it does — explain *why* it behaves that way, what design choice it reflects, or what would break if it changed.
    

      

    
  
  
  


  

    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
String a = new String("hello");
String b = new String("hello");
System.out.println(a == b);        // Line A
System.out.println(a.equals(b));   // Line B

Predict each output. Then explain why Line A and Line B differ — what does each operator actually check?


      

        
Line A: false. Line B: true.

== checks reference identity — are a and b the same object in memory? new String(...) forces a fresh heap allocation each time, so a and b are two different objects.

.equals() checks value equality — do the two Strings contain the same characters? They do, so it returns true.

Key insight: Java’s == is always a reference comparison for objects. Unlike Python’s == (value comparison) and C++’s == (overloadable per class), Java’s == never examines content.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Integer x = 127;
Integer y = 127;
System.out.println(x == y);   // true

Integer p = 128;
Integer q = 128;
System.out.println(p == q);   // false

The only change is 127 → 128. What mechanism in the JVM causes this flip, and why is this dangerous in production code?


      

        
Java pre-creates and caches Integer objects for values −128 to 127 at JVM startup. Autoboxing Integer x = 127 hands back the same cached object every time, so x == y is true (same reference).

Outside the cache range, Integer.valueOf(128) creates a new heap object each call. p and q point to different objects — == returns false.

Why dangerous: Tests usually use small values (IDs, counts) that fall in the cache range. == appears to work. In production, large IDs or counts fall outside the cache and == silently returns false. The fix is always .equals() for wrapper types.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Integer count = null;
int n = count;  // what happens here?

Describe exactly what the JVM does on the second line and what error results.


      

        
Auto-unboxing is syntactic sugar. The second line expands to:
int n = count.intValue();

Calling .intValue() on null throws a NullPointerException — the JVM cannot dereference a null reference.

This is a common production bug because Integer fields default to null (not 0), and database queries returning no row often produce null wrapper values.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
// Version A
Integer sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;
}

// Version B
int sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;
}

Both produce the same final value. Analyze what the JVM does differently in Version A on every iteration. Which version should you use?


      

        
Version A expands sum += i to:
sum = Integer.valueOf(sum.intValue() + i);

That is two method calls and one new Integer object allocation per iteration — one million short-lived objects in total, generating garbage-collector pressure.

Version B performs pure stack arithmetic — no objects created, no method calls.

Use Version B. Use primitive types for accumulators and counters. Use wrapper types only when generics (List<Integer>), nullable values, or object methods (.compareTo()) require them.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Basic
      
      
      
public class BankAccount {
    public String owner;
    public double balance;
    ...
}

The fields are public. Explain what specific harm this causes compared to making them private with a withdraw() method that validates before mutating.


      

        
With public fields, any class can set balance to any value — including negative amounts or values that bypass business rules. There is no enforcement point.

account.balance = -999.0;  // completely legal — no way to prevent this


With private double balance and a withdraw() method, all mutations go through one gate where you can enforce invariants:
public boolean withdraw(double amount) {
    if (amount > 0 && balance >= amount) { balance -= amount; return true; }
    return false;
}


This is the core value of encapsulation: validation cannot be bypassed because callers have no path to the field directly.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
class GradeReport {
    private ArrayList<Integer> scores;

    public ArrayList<Integer> getScores() { return scores; }
}

The field is private. A colleague says “information hiding is achieved.” Are they right? What would break if you later switch scores to int[]?


      

        
Wrong. The field is encapsulated (private), but information hiding is not achieved.

The return type ArrayList<Integer> exposes the storage decision as part of the public API. Every caller of getScores() now depends on ArrayList. If you switch to int[]:

// These callers break immediately:
ArrayList<Integer> s = report.getScores();
s.iterator();    // int[] has no iterator()


Proper information hiding exposes behavior, not data structure:

  
getAverage() — hides that you store an ArrayList
  
getLetterGrade(int score) — hides the grading policy
  
formatReport() — hides the output format


After this refactoring, switching from ArrayList to int[] changes exactly one class.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
public interface Shape {
    double getArea();
    double getPerimeter();
}

public class Circle implements Shape {
    private double radius;
    public Circle(double r) { this.radius = r; }

    @Override
    public double getArea() { return Math.PI * radius * radius; }

    @Override
    public double getPerimeter() { return 2 * Math.PI * radius; }
}

Shape s = new Circle(5.0);
System.out.println(s.getArea());

Explain what @Override buys you here. Give an example of the specific bug it prevents.


      

        
@Override instructs the compiler to verify that the annotated method actually overrides something in the parent class or interface.

Without it, a typo silently creates a new method instead of overriding:

// Without @Override — compiles, but never called polymorphically
public double getArae() { return Math.PI * radius * radius; }  // typo!


With @Override:
@Override
public double getArae() { ... }  // COMPILE ERROR: method does not override


It also catches the case where an interface method is renamed — the override becomes a dead method silently if @Override is absent.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
abstract class Vehicle {
    private String make;
    public Vehicle(String make) { this.make = make; }
    public String getMake() { return make; }
    public abstract String describe();
}

class Car extends Vehicle {
    public Car(String make) {
        super(make);       // ← this line
    }
    @Override
    public String describe() { return getMake() + " Car"; }
}

Why must super(make) be the first statement in Car’s constructor? What would happen if it were moved after getMake()?


      

        
Java requires the parent’s constructor to run before any subclass code, because the subclass may depend on state initialized by the parent. If super() is not the first statement, a partially-constructed Vehicle could be accessed.

If you tried to move super(make) below a getMake() call:
public Car(String make) {
    getMake();    // compile error — super() must come first
    super(make);
}

The compiler enforces this: if no explicit super() or this() is the first line, Java implicitly inserts super() (the no-arg parent constructor). If the parent has no no-arg constructor, compilation fails.

In C++, the equivalent constraint is enforced through initializer lists: Car(String make) : Vehicle(make) { }.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Vehicle[] fleet = {
    new Car("Toyota", 2024),
    new Motorcycle("Harley", 2023),
};
for (Vehicle v : fleet) {
    System.out.println(v.describe());
}

The reference type is Vehicle, but describe() is abstract. Describe precisely what happens at compile time and at runtime when v.describe() is called.


      

        
Compile time: The compiler checks that describe() is declared in the static type of v, which is Vehicle. Since Vehicle declares abstract String describe(), the call is legal. The compiler does not know which implementation will run.

Runtime: The JVM uses dynamic dispatch (virtual method table lookup). It examines the actual type of the object — Car or Motorcycle — and calls that class’s describe() implementation. The reference type Vehicle is irrelevant at this point.

This is Java’s default behavior for all non-static, non-final methods. Unlike C++, where virtual dispatch requires the virtual keyword, every Java method is effectively virtual.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Expert
      
      
      
public class Pair<A, B> {
    private A first;
    private B second;

    public static <X, Y> Pair<Y, X> swap(Pair<X, Y> p) {
        return new Pair<>(p.getSecond(), p.getFirst());
    }
}

Why does swap declare its own type parameters <X, Y> instead of reusing the class’s <A, B>?


      

        
swap is static — it has no access to the instance’s type parameters A and B, because statics exist on the class, not on any particular Pair<A, B> instance.

<X, Y> are fresh parameters scoped to this method call, letting the compiler infer types from the argument:

Pair<String, Integer> p = new Pair<>("Alice", 95);
Pair<Integer, String> swapped = Pair.swap(p);
// Compiler infers: X=String, Y=Integer → returns Pair<Integer, String>


If swap used A and B directly, a static method would need to belong to a specific Pair<A, B>, which is impossible. The method-level parameters <X, Y> make swap work for any Pair, not just one with a specific concrete type.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Map<String, Integer> scores = new HashMap<>();
scores.put("Alice", 95);
int grade = scores.get("Bob");  // Bob not in map

This compiles without warnings. Predict what happens at runtime and explain the chain of events.


      

        
Runtime: NullPointerException.

Step-by-step:

  
scores.get("Bob") — "Bob" is not a key, so HashMap.get() returns null (not 0, not an exception)
  
int grade = null — auto-unboxing expands this to null.intValue()
  
Calling .intValue() on a null reference throws NullPointerException


Fixes:
int grade = scores.getOrDefault("Bob", 0);     // concise
// or
if (scores.containsKey("Bob")) { grade = scores.get("Bob"); }


This is one of the most common Java production bugs: HashMap silently returns null, and the NPE appears at the unboxing site, which is often far from where the missing key was introduced.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
public class SafeCalculator {
    public double divide(int a, int b) throws CalculatorException {
        if (b == 0) throw new CalculatorException("Division by zero");
        return (double) a / b;
    }
}

class CalculatorException extends Exception {
    public CalculatorException(String msg) { super(msg); }
}

CalculatorException extends Exception, not RuntimeException. What concrete difference does this choice produce for callers of divide()?


      

        
Because CalculatorException is checked (extends Exception), the compiler forces every caller to either:

  
Catch it: try { calc.divide(10, 0); } catch (CalculatorException e) { ... }
  
Or propagate it: public void run() throws CalculatorException { ... }


If CalculatorException extended RuntimeException, callers could ignore it entirely — the exception would propagate silently until it crashed the program at runtime.

The design choice says: “Division by zero is a recoverable situation the caller should explicitly decide how to handle” — not a programmer error. This is appropriate for library APIs where you want to force callers to think about failure modes.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
// Version A
public double average(ArrayList<Integer> scores) { ... }

// Version B
public double average(List<Integer> scores) { ... }

Both compile. Analyze the practical difference when other code calls average().


      

        
Version A forces callers to pass an ArrayList specifically:
average(new ArrayList<>(...));   // works
average(new LinkedList<>(...));  // compile error!


Version B accepts any List implementation:
average(new ArrayList<>(...));   // works
average(new LinkedList<>(...));  // works
average(Arrays.asList(1,2,3));   // works — Arrays.asList returns a List, not ArrayList


Version B is correct. The parameter should be the narrowest interface that expresses what the method actually needs. average() only needs to iterate — that’s a List contract, not an ArrayList one. Using ArrayList couples callers to an implementation detail the method doesn’t actually require.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Set<String> submitted = new HashSet<>();
List<String> roster = new ArrayList<>();

submitted.add("Alice");
submitted.add("Alice");  // duplicate

roster.add("Alice");
roster.add("Alice");     // duplicate

System.out.println(submitted.size());  // ?
System.out.println(roster.size());     // ?

Predict each output and explain what design principle drives the difference between HashSet and ArrayList.


      

        

  
submitted.size() → 1
  
roster.size() → 2


HashSet implements the Set contract: a collection with no duplicate elements. add() silently ignores values already present.

ArrayList implements the List contract: an ordered sequence that allows duplicates. Each add() appends unconditionally.

Design principle: The collection type encodes your invariant — what the data is allowed to contain. Choosing HashSet for submitted assignments is not just a performance choice; it’s a semantic declaration that “a student can only submit once.” ArrayList gives you no such guarantee.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
public class Course implements Enrollable {
    private ArrayList<Student> students = new ArrayList<>();

    public boolean isEnrolled(String name) {
        for (Student s : students) {
            if (s.getName().equals(name)) return true;
        }
        return false;
    }
}

This works correctly. Evaluate it for performance and explain what would change if you swapped ArrayList<Student> for HashMap<String, Student>.


      

        
Current: isEnrolled() is O(n) — it scans every student linearly until a match is found. For a large course (or many isEnrolled calls), this is slow.

With HashMap<String, Student> keyed by name:
private HashMap<String, Student> students = new HashMap<>();

public boolean isEnrolled(String name) {
    return students.containsKey(name);  // O(1) hash lookup
}


The tradeoff: HashMap loses insertion order (use LinkedHashMap to preserve it), but gains O(1) lookup. For a Course.isEnrolled() called frequently (e.g., every time someone tries to enroll), the O(1) version is significantly better.

Information-hiding perspective: Because students is private, this switch only modifies one class — no callers break. This is the payoff of information hiding.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
  

  

    

      
Workout Complete!
      

        Your Score: 0/15
      
      
Come back later to improve your recall!
      

        Restart Workout
        Review Incorrect Cards
      
    
  


















  

    

      
Java — Write the Code
      
      
        
      
      
    
    
You are given a scenario or design problem. Write Java code that solves it. Questions target Apply, Evaluate, and Create levels — not just syntax recall.
    

      

    
  
  
  


  

    
    

      
      
      
        Difficulty:
        Basic
      
      
      
[Apply] Two String variables input and stored may or may not point to the same object. Write a boolean expression that checks whether they contain the same characters, guaranteed to be correct regardless of how they were created.


      

        
input.equals(stored)

        
.equals() compares character content regardless of object identity. == would fail whenever input and stored are separate objects with identical content — for example, when stored came from a database query and input came from user input.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
[Evaluate + Apply] A HashMap lookup is crashing in production with a NullPointerException. The code is:
Map<String, Integer> grades = loadFromDB();
int g = grades.get(studentId);

Fix it in one line, defaulting to 0 for missing students.


      

        
int g = grades.getOrDefault(studentId, 0);

        
HashMap.get() returns null for missing keys. Auto-unboxing null to int throws NPE. getOrDefault(key, fallback) returns the value if present, or the fallback safely — no null, no NPE. Alternatively: grades.containsKey(studentId) ? grades.get(studentId) : 0, but getOrDefault is more idiomatic.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
[Create] Design a BankAccount class that:

  
Stores owner (String) and balance (double) — neither directly accessible from outside
  
Provides a constructor, getOwner(), getBalance()
  
deposit(double amount) — only accepts positive amounts
  
withdraw(double amount) — returns false if insufficient funds; true on success
  
toString() returns "BankAccount[owner=Alice, balance=100.0]"



      

        
public class BankAccount {
    private String owner;
    private double balance;

    public BankAccount(String owner, double initial) {
        this.owner = owner;
        this.balance = initial;
    }

    public String getOwner()   { return owner; }
    public double getBalance() { return balance; }

    public void deposit(double amount) {
        if (amount > 0) balance += amount;
    }

    public boolean withdraw(double amount) {
        if (amount > 0 && balance >= amount) {
            balance -= amount;
            return true;
        }
        return false;
    }

    @Override
    public String toString() {
        return "BankAccount[owner=" + owner + ", balance=" + balance + "]";
    }
}


        
Private fields + validated methods = encapsulation. The withdraw boolean return avoids throwing an exception for an expected condition (insufficient funds isn’t a programming error). toString() is annotated @Override — the compiler verifies we’re overriding Object.toString().

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
[Evaluate + Create] This class has a design problem. Identify it, then rewrite GradeReport so that changing the grading thresholds (A ≥ 90, B ≥ 80…) requires editing only one method:
class GradeReport {
    private List<Integer> scores;
    public List<Integer> getScores() { return scores; }
}

// In main:
for (int s : report.getScores()) {
    if (s >= 90) System.out.println("A");
    else if (s >= 80) System.out.println("B");
}



      

        
Problem: The grading policy leaks into main. Changing thresholds requires editing every call site.

class GradeReport {
    private List<Integer> scores = new ArrayList<>();

    public void addScore(int score) { scores.add(score); }

    // Hides the grading policy — change thresholds in ONE place
    public String getLetterGrade(int score) {
        if (score >= 90) return "A";
        if (score >= 80) return "B";
        if (score >= 70) return "C";
        if (score >= 60) return "D";
        return "F";
    }

    // Hides the data representation — callers never see ArrayList
    public double getAverage() {
        int sum = 0;
        for (int s : scores) sum += s;
        return sum / (double) scores.size();
    }

    // Hides the output format — change to CSV here, nothing else changes
    public String formatReport(String name) {
        StringBuilder sb = new StringBuilder("Report: " + name + "\n");
        for (int s : scores)
            sb.append("  ").append(s).append(" (").append(getLetterGrade(s)).append(")\n");
        sb.append("Average: ").append(getAverage());
        return sb.toString();
    }
}


        
This is Parnas’s information hiding principle in action. Three secrets are now hidden: grading policy (in getLetterGrade), data representation (no getScores() exposed), output format (in formatReport). Changing any of them touches exactly one method.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Basic
      
      
      
[Apply] Define a Drawable interface with one method: String draw(). Then write a Square class that implements it — draw() returns "Square(side=5.0)".


      

        
public interface Drawable {
    String draw();
}

public class Square implements Drawable {
    private double side;

    public Square(double side) { this.side = side; }

    @Override
    public String draw() {
        return "Square(side=" + side + ")";
    }
}


        
Interface methods are implicitly public abstract. The implementing class uses implements (not extends). Every method declared in the interface must be implemented — the compiler enforces this. @Override confirms the method matches the interface signature.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
[Create] Design an abstract class Animal with:

  
A private String name and a constructor
  
A concrete getName() getter
  
An abstract method makeSound() that returns a String


Then write a Dog subclass that calls the parent constructor and returns "Woof!" from makeSound().


      

        
public abstract class Animal {
    private String name;

    public Animal(String name) { this.name = name; }

    public String getName() { return name; }

    public abstract String makeSound();
}

public class Dog extends Animal {
    public Dog(String name) {
        super(name);   // must be first — initializes parent's private field
    }

    @Override
    public String makeSound() { return "Woof!"; }
}


        
super(name) must be the first statement — it runs the parent constructor before any Dog-specific code. Because name is private in Animal, Dog cannot access it directly — it uses getName(). The abstract keyword on makeSound() forces every concrete subclass to provide an implementation.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Basic
      
      
      
[Apply] Write a generic class Box<T> that holds one item of any type. Include a constructor, a getItem() method, and a setItem() method.


      

        
public class Box<T> {
    private T item;

    public Box(T item) { this.item = item; }

    public T getItem()           { return item; }
    public void setItem(T item)  { this.item = item; }
}

// Usage:
Box<String> nameBox = new Box<>("Alice");
String name = nameBox.getItem();   // no cast needed — compiler knows it's String

Box<Integer> numBox = new Box<>(42);
int n = numBox.getItem();          // auto-unboxing Integer → int


        
<T> is a type parameter — a placeholder filled in at the call site. The compiler uses it to insert correct types and casts, catching mismatches at compile time instead of runtime. Box<int> is illegal — use Box<Integer> since generics require object types (due to type erasure).

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Expert
      
      
      
[Apply + Analyze] Write a generic static method findMax that takes two arguments of any type and returns the larger one. The type must be constrained to types that can be compared.


      

        
public static <T extends Comparable<T>> T findMax(T a, T b) {
    return a.compareTo(b) >= 0 ? a : b;
}

// Usage:
System.out.println(findMax("apple", "banana"));  // "banana"
System.out.println(findMax(3, 7));               // 7


        
<T extends Comparable<T>> is a bounded type parameter — it restricts T to types that implement Comparable. This is the Java equivalent of C++20 concepts. Without the bound, the compiler would reject a.compareTo(b) because it can’t guarantee T has that method. String, Integer, Double all implement Comparable.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
[Create] Write a WordCounter class that takes a String[] in its constructor and provides:

  
int getCount(String word) — returns 0 for unknown words, no NPE
  
int getUniqueCount() — number of distinct words


Use the most appropriate collection for each responsibility.


      

        
import java.util.HashMap;
import java.util.HashSet;

public class WordCounter {
    private HashMap<String, Integer> counts   = new HashMap<>();
    private HashSet<String>         unique    = new HashSet<>();

    public WordCounter(String[] words) {
        for (String w : words) {
            unique.add(w);                                // HashSet deduplicates
            counts.put(w, counts.getOrDefault(w, 0) + 1); // HashMap counts
        }
    }

    public int getCount(String word) {
        return counts.getOrDefault(word, 0);  // safe — no NPE on missing key
    }

    public int getUniqueCount() {
        return unique.size();
    }
}


        
HashMap<String, Integer> maps each word to its frequency — O(1) insert and lookup. HashSet<String> tracks distinct words — O(1) add with automatic deduplication. getOrDefault(word, 0) avoids the NPE that get() followed by auto-unboxing would cause for missing keys.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
[Apply] Define a checked exception EnrollmentException and a Course.enroll(Student s) method that throws it when the course is full (capacity exceeded). Write both the class definition and the calling code that handles the exception.


      

        
public class EnrollmentException extends Exception {
    public EnrollmentException(String message) {
        super(message);   // passes message to Exception's constructor
    }
}

public class Course {
    private int capacity;
    private List<Student> students = new ArrayList<>();

    public Course(int capacity) { this.capacity = capacity; }

    public void enroll(Student s) throws EnrollmentException {
        if (students.size() >= capacity) {
            throw new EnrollmentException("Course is full");
        }
        students.add(s);
    }
}

// Calling code — compiler forces handling
try {
    course.enroll(new Student("Alice", 1001));
} catch (EnrollmentException e) {
    System.out.println("Could not enroll: " + e.getMessage());
}


        
Extending Exception (not RuntimeException) makes it checked — callers must catch or re-throw it. The throws EnrollmentException in the method signature is part of the contract and required by the compiler. super(message) stores the message in Exception, making it available via getMessage().

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
[Apply] Write a try-catch-finally block that: opens a file (throws IOException), reads its content, and prints an error if it fails. The finally block should always print "Done.".


      

        
try {
    String content = readFile("data.txt");   // throws IOException
    System.out.println(content);
} catch (IOException e) {
    System.err.println("File error: " + e.getMessage());
} finally {
    System.out.println("Done.");   // always runs — exception or not
}


        
catch (IOException e) handles IOException and all its subclasses (e.g., FileNotFoundException). finally runs whether or not an exception was thrown — use it for cleanup (closing streams, releasing locks). Even if the catch block re-throws, finally still runs.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
[Evaluate + Apply] You need to store course enrollments. Two options:

  
List<Student> with a manual duplicate check in enroll()
  
LinkedHashSet<Student> that handles duplicates automatically


Implement enroll(Student s) using each approach, then state which is preferable and why.


      

        
// Option A: List — manual duplicate check
private List<Student> students = new ArrayList<>();
public void enroll(Student s) {
    if (!students.contains(s)) students.add(s);
}

// Option B: LinkedHashSet — automatic deduplication, insertion order preserved
private LinkedHashSet<Student> students = new LinkedHashSet<>();
public void enroll(Student s) {
    students.add(s);   // ignored if already present — no check needed
}


Option B is preferable. LinkedHashSet.add() is O(1) and the “no duplicates” invariant is enforced by the type — you cannot accidentally skip the check. List.contains() is O(n) and the invariant is only enforced if every enroll() caller remembers to check. Choose a collection whose contract matches your invariant.

        
Choosing the right collection encodes intent. Set means ‘unique elements’ — the type enforces the invariant. List means ‘ordered sequence with possible duplicates’ — you must enforce uniqueness manually, which is fragile. LinkedHashSet adds insertion-order iteration over plain HashSet.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
[Apply] Write a method printAll(List<String> items) that iterates the list with an enhanced for-loop, printing each item. Then call it with an ArrayList<String> and a LinkedList<String>. Explain why both calls compile.


      

        
public void printAll(List<String> items) {
    for (String item : items) {
        System.out.println(item);
    }
}

// Both compile because both implement List<String>
List<String> array  = new ArrayList<>(Arrays.asList("a", "b"));
List<String> linked = new LinkedList<>(Arrays.asList("c", "d"));

printAll(array);   // fine
printAll(linked);  // fine


        
Declaring the parameter as List<String> (the interface) rather than ArrayList<String> (the concrete class) allows any List implementation to be passed. This is ‘program to an interface, not an implementation.’ The enhanced for-loop works on any Iterable, which both ArrayList and LinkedList implement through List.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
[Create] You are building a course registration system. Design the method signature (interface method + throws) for an Enrollable interface that:

  
Adds a student (can fail if course is full or duplicate)
  
Removes a student by name (returns whether it succeeded)
  
Checks enrollment by name
  
Returns a list of enrolled student names



      

        
import java.util.ArrayList;

public interface Enrollable {
    // Throws checked exception — caller must handle enrollment failures
    void enroll(Student student) throws EnrollmentException;

    // Returns false if student not found — boolean, not exception (expected condition)
    boolean drop(String name);

    // Pure lookup — no side effects, no exception
    boolean isEnrolled(String name);

    // Returns names only — hides Student objects from caller
    ArrayList<String> getRoster();
}


        
enroll() throws a checked exception because a full course is an external condition the caller should handle. drop() returns boolean because dropping a non-existent student is a non-exceptional expected case. getRoster() returns ArrayList<String> (names) rather than exposing Student objects — this hides the internal Student type from consumers of the interface.

      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
[Evaluate + Create] A teammate wrote this accumulator. Find the performance issue, explain the root cause, and write the corrected version.
Integer total = 0;
for (String word : words) {
    if (word.length() > 5) total++;
}



      

        
Issue: total++ expands to total = Integer.valueOf(total.intValue() + 1) — an object allocation on every iteration for an Integer that is immediately discarded.

Root cause: Integer is a wrapper (heap object). Using it as an accumulator creates one new object per loop iteration, generating garbage-collector pressure.

// Corrected — use primitive int for the counter
int total = 0;
for (String word : words) {
    if (word.length() > 5) total++;
}


Use Integer only when the type system requires it: generic containers (List<Integer>), nullable fields, or calling methods like .compareTo(). For local counters and accumulators, always use int.

        


      

      

        Show Answer
        

          
            ✔
          
          
            ✖
          
        
      
    
    
  

  

    

      
Workout Complete!
      

        Your Score: 0/15
      
      
Come back later to improve your recall!
      

        Restart Workout
        Review Incorrect Cards
      
    
  


















  

    

      
Java Concepts Quiz
      
      
        
      
      
    
    
Test your deeper understanding of Java's type system, OOP model, and design idioms. Covers false friends with C++/Python, encapsulation vs information hiding, generics, collections, and exception handling. Includes Parsons problems, technique-selection questions, and spaced interleaving across all concepts.
    

      

    
  
  
  


  

    
    

      
      
      
        Difficulty:
        Basic
      
      
      
Predict the output of this code:
String a = new String("hello");
String b = new String("hello");
System.out.println(a == b);
System.out.println(a.equals(b));


      
      
      

        
        
        
          
          A
          
true, true

        
        
        
        
        
        
new String("hello") creates two separate objects, so reference equality is false even though
the characters match.

        
        
        
        
          
          B
          
false, true

        
        
        
        
        
        
        
        
          
          C
          
false, false

        
        
        
        
        
        
The two objects have the same character content. .equals() is designed to compare that content
for String.

        
        
        
        
          
          D
          
true, false — == uses the interned pool so it’s true, but equals() checks identity

        
        
        
        
        
        
== compares references for objects; it does not use string interning to make two explicit new
String(...) objects equal. .equals() is the content comparison.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
new String() bypasses the intern pool, so == returns false (different references) while .equals() returns true (same content) — never use == to compare strings. new String("hello") forces Java to create a fresh object on the heap each time, bypassing the string intern pool. So a and b are different objects — == compares references and returns false. .equals() compares character content and returns true. The lesson: never use == to compare strings. Always use .equals().

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
What does this code print?
Integer x = 200;
Integer y = 200;
System.out.println(x == y);
System.out.println(x.equals(y));


      
      
      

        
        
        
          
          A
          
true, true — autoboxing reuses the same object

        
        
        
        
        
        
Autoboxing reuses some boxed integers, but not all of them. The standard cache covers small
values such as -128 through 127, not 200.

        
        
        
        
          
          B
          
false, true — Java caches Integer objects only for -128 to 127; 200 creates two separate heap objects, so == compares references

        
        
        
        
        
        
        
        
          
          C
          
Compile error — == cannot be applied to Integer

        
        
        
        
        
        
== can be applied to Integer references. The dangerous part is that it compares object
identity rather than numeric value.

        
        
        
        
          
          D
          
true, false — == compares values for boxed integers

        
        
        
        
        
        
== does not generally compare boxed integer values. .equals() gives the numeric value
comparison here.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Java only caches Integer values from -128 to 127, so 200 creates two separate heap objects — == returns false but .equals() returns true. Java maintains an Integer cache for values −128 to 127. Outside this range, autoboxing calls Integer.valueOf(200) which creates a new object each time. So x and y point to different objects — == returns false. .equals() compares the values and returns true. This is why you must always use .equals() for wrapper types, not ==.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
What happens at runtime when this code executes?
Integer count = null;
int n = count;


      
      
      

        
        
        
          
          A
          
n is assigned 0 — the default value for int

        
        
        
        
        
        
Java does not use 0 as the value of a null boxed integer. Unboxing needs an actual Integer
object to call.

        
        
        
        
          
          B
          
NullPointerException — auto-unboxing calls .intValue() on null, which throws

        
        
        
        
        
        
        
        
          
          C
          
Compile error — you cannot assign Integer to int

        
        
        
        
        
        
Assigning an Integer to an int is allowed through auto-unboxing. It fails at runtime here
because the reference is null.

        
        
        
        
          
          D
          
n is assigned -1 — Java uses -1 as a null sentinel for int

        
        
        
        
        
        
Java has no -1 null sentinel for primitive int. The unboxing operation throws before any
primitive value can be assigned.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Auto-unboxing calls .intValue() on the Integer, so assigning null to int throws NullPointerException — always check for null before unboxing. Auto-unboxing is syntactic sugar for .intValue(). When count is null, calling .intValue() on it throws NullPointerException. This is a common production bug — it works fine in testing (where counts are small non-null numbers) and explodes in production when a database returns null. Always check for null before unboxing.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
A teammate writes this in a hot loop:
Integer sum = 0;
for (int i = 0; i < 1_000_000; i++) {
    sum += i;
}

You suggest changing Integer sum to int sum. What is the precise reason?

      
      
      

        
        
        
          
          A
          
There is no meaningful difference — the JIT compiler optimizes the boxing away

        
        
        
        
        
        
The JIT may optimize some cases, but relying on it hides the real cost model. Integer
arithmetic can create boxing and unboxing overhead that primitive int avoids.

        
        
        
        
          
          B
          
Each sum += i unboxes sum to int, adds i, then boxes the result back into a new Integer object — one million heap allocations. int sum keeps everything on the stack with pure arithmetic.

        
        
        
        
        
        
        
        
          
          C
          
Integer is 64-bit but int is 32-bit, so int is faster for addition

        
        
        
        
        
        
Integer wraps a 32-bit int, not a 64-bit value. The performance issue is boxing, not integer
width.

        
        
        
        
          
          D
          
Integer does not support the += compound operator

        
        
        
        
        
        
The compound operator is legal with Integer because Java unboxes and reboxes. That automatic
conversion is exactly the cost being avoided.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Each += on an Integer causes an unbox, add, and rebox — one heap allocation per iteration, creating enormous GC pressure that int avoids entirely. sum += i expands to sum = Integer.valueOf(sum.intValue() + i) — two method calls and one object allocation per iteration. In a tight loop this creates enormous garbage-collector pressure. Use primitive int for accumulators, counters, and any variable that is never put into a generic container.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Basic
      
      
      
In Java, what is the default access level when no access modifier is specified on a field or method?

      
      
      

        
        
        
          
          A
          
private — only accessible within the class (same as C++ class default)

        
        
        
        
        
        
This is a C++ transfer error. Java’s no-modifier access is package-private, not private.

        
        
        
        
          
          B
          
package-private — accessible to any class in the same package

        
        
        
        
        
        
        
        
          
          C
          
public — accessible from anywhere

        
        
        
        
        
        
Java does not make unmarked members public. Public access requires the explicit public
modifier.

        
        
        
        
          
          D
          
protected — accessible to subclasses and the same package

        
        
        
        
        
        
Protected access includes subclasses and package access, but default Java access is
package-private only.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Unlike C++ where the default is private, Java’s default is package-private — any class in the same package can access the member without an explicit modifier. This is a key false friend from C++. In a C++ class, the default access is private. In Java, the default is package-private — any class in the same package can read or write the member without any access modifier. This is a common source of accidental data exposure when transitioning from C++. Always be explicit with Java access modifiers.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
A GradeReport class has private ArrayList<Integer> scores and exposes it like this:
public ArrayList<Integer> getScores() { return scores; }

All fields are private. Has information hiding (Parnas 1972) been achieved?

      
      
      

        
        
        
          
          A
          
Yes — the field is private, so the internal representation is fully hidden

        
        
        
        
        
        
Private fields are only part of the story. Returning ArrayList<Integer> exposes the
representation choice through the public API.

        
        
        
        
          
          B
          
No — the return type ArrayList<Integer> leaks the storage decision. Switching to int[] or a database would break every caller of getScores().

        
        
        
        
        
        
        
        
          
          C
          
Yes — information hiding and encapsulation are the same concept

        
        
        
        
        
        
Encapsulation and information hiding are related but not identical. A field can be private while
the design decision behind it is still exposed.

        
        
        
        
          
          D
          
Partially — the ArrayList is hidden, but the Integer type is exposed

        
        
        
        
        
        
The ArrayList itself is not hidden when it appears in the method signature. Callers can now
depend on list-specific behavior.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Information hiding is NOT achieved because the return type ArrayList<Integer> exposes the storage decision — switching to int[] or a database would break every caller. Encapsulation (private fields) and information hiding are orthogonal. The field is encapsulated, but the method signature exposes the secret — the choice of ArrayList<Integer>. When storage changes, every caller breaks. A properly hidden design exposes behavior instead: getAverage(), getLetterGrade(int score), formatReport(). Callers never see how scores are stored.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Basic
      
      
      
Dog, Car, and Printer each need a serialize() method. They share no fields or common behavior. Which Java construct is the right fit?

      
      
      

        
        
        
          
          A
          
An abstract class Serializable that all three extend — abstract classes define shared contracts

        
        
        
        
        
        
An abstract class is best when related classes share implementation or state. These classes only
share a capability.

        
        
        
        
          
          B
          
An interface Serializable that all three implement — unrelated classes share a contract, not state or implementation

        
        
        
        
        
        
        
        
          
          C
          
A concrete base class Serializable with a default serialize() body that each class can override

        
        
        
        
        
        
A concrete base class would create an artificial inheritance relationship among unrelated types.
The shared idea is a contract, not a common ancestor with state.

        
        
        
        
          
          D
          
Generics — class Serializable<T> allows serialize() to be parameterized

        
        
        
        
        
        
Generics parameterize types; they do not by themselves define a shared method contract for
unrelated classes.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
An interface is correct here because the three classes are unrelated and share a behavioral contract only — an abstract class would be appropriate only if they also shared state or implementation. Interfaces define contracts for unrelated classes that share behavior but no state. Abstract classes make sense when related classes share both fields and some concrete methods. Dog, Car, and Printer are completely unrelated — an interface is correct. This matches Java’s own java.io.Serializable. If the three classes also shared a createdAt field and a log() implementation, an abstract class would be appropriate.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
Why is ArrayList<int> illegal in Java, while vector<int> is valid in C++?

      
      
      

        
        
        
          
          A
          
ArrayList only supports String and Object types

        
        
        
        
        
        
ArrayList can store any reference type, not only String and Object. The problem is that
int is primitive, not a reference type.

        
        
        
        
          
          B
          
Java generics use type erasure — they erase to Object at runtime. The primitive int is not an Object and cannot be cast to one. Use ArrayList<Integer> instead.

        
        
        
        
        
        
        
        
          
          C
          
You need to import java.util.primitives to use int with generics

        
        
        
        
        
        
There is no import that makes Java generics accept primitives directly. Use wrapper types such
as Integer.

        
        
        
        
          
          D
          
ArrayList is valid — it is equivalent to ArrayList

        
        
        
        
        
        
Java does not silently rewrite ArrayList<int> into ArrayList<Integer>. The source type
argument must already be a reference type.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Java generics use type erasure and erase to Object, so primitives like int — which are not Object subtypes — cannot be used as type parameters; use Integer instead. C++ templates generate separate code for each instantiation — vector<int> and vector<string> are distinct compiled types. Java uses type erasure: there is one compiled ArrayList class, and generic type parameters become Object after compilation. Since int is not a subtype of Object, it cannot be used as a type parameter. Wrap it with Integer (autoboxing handles the conversion automatically).

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Expert
      
      
      
This code does not compile. Why?
public boolean isStringList(List<?> list) {
    return list instanceof List<String>;
}


      
      
      

        
        
        
          
          A
          
instanceof requires an interface, not a class

        
        
        
        
        
        
instanceof works with classes and interfaces. The rejected part is the parameterized type
List<String> after erasure.

        
        
        
        
          
          B
          
Generic types are erased at runtime — List<String> and List<Integer> are both just List. The compiler rejects the check because it can never be meaningful.

        
        
        
        
        
        
        
        
          
          C
          
You need a cast before using instanceof on a generic type

        
        
        
        
        
        
A cast cannot recover erased generic element types. The JVM still cannot know whether a runtime
List was intended as List<String>.

        
        
        
        
          
          D
          
instanceof doesn’t work on interface types like List

        
        
        
        
        
        
instanceof List<?> is valid. The issue is asking about the erased element type, not checking
an interface.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Type erasure makes List<String> and List<Integer> identical at runtime, so the compiler rejects instanceof List<String> as a meaningless check. After type erasure, the JVM cannot distinguish List<String> from List<Integer> — both are just List. So instanceof List<String> would be an unsound check, and the compiler rejects it. You can write instanceof List<?> (unbounded wildcard) to test whether something is any list, but you lose the type information.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
[Technique Selection] Match each task to the best collection:

  
A: Track which students have submitted homework (no duplicates, O(1) lookup by name)
  
B: Map each student ID (int) to their final grade (double)
  
C: Maintain an ordered history of grade submissions (newest at the end, access by index)


      
      
      

        
        
        
          
          A
          
A: HashSet, B: HashMap, C: ArrayList

        
        
        
        
        
        
        
        
          
          B
          
A: ArrayList, B: HashSet, C: HashMap

        
        
        
        
        
        
ArrayList preserves order, but membership checks are linear and duplicates need manual
prevention. That does not fit fast lookup with no duplicates.

        
        
        
        
          
          C
          
A: HashMap, B: ArrayList, C: HashSet

        
        
        
        
        
        
A HashMap maps keys to values; it is not the natural representation for task A’s set
membership or task C’s ordered history.

        
        
        
        
          
          D
          
A: HashSet, B: ArrayList, C: HashMap

        
        
        
        
        
        
A HashMap does not preserve an ordered grade-submission history by index. It is for
key-to-value lookup.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
HashSet gives O(1) deduplication lookup, HashMap gives key-to-value mapping, and ArrayList gives ordered index access — each matches its task’s requirement precisely. HashSet<String> gives O(1) contains() and automatic deduplication. HashMap<Integer, Double> maps student IDs (keys) to grades (values). ArrayList<Double> maintains insertion order with O(1) index access. Using ArrayList for the submission tracker would require O(n) contains() checks and manual duplicate prevention.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
What is the bug in this code?
Map<String, Integer> scores = new HashMap<>();
scores.put("Alice", 95);
int grade = scores.get("Bob");


      
      
      

        
        
        
          
          A
          
HashMap does not support String keys

        
        
        
        
        
        
HashMap fully supports String keys. The failure happens when a missing key produces null
and Java tries to unbox it.

        
        
        
        
          
          B
          
NullPointerException — get() returns null for missing keys, and unboxing null to int throws

        
        
        
        
        
        
        
        
          
          C
          
Compile error — get() returns Object, which cannot be assigned to int

        
        
        
        
        
        
With generics, scores.get("Bob") has type Integer, not raw Object. Auto-unboxing is
allowed but fails on null.

        
        
        
        
          
          D
          
Nothing — the default value 0 is returned for missing keys

        
        
        
        
        
        
HashMap.get() returns null for a missing key, not 0. A default value requires
getOrDefault() or explicit handling.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
HashMap.get() returns null for missing keys, and auto-unboxing that null to int throws NullPointerException — use getOrDefault() or check containsKey() first. HashMap.get() returns null when the key is not present. Auto-unboxing calls .intValue() on null, throwing NullPointerException. Fix: use scores.getOrDefault("Bob", 0), or check scores.containsKey("Bob") before calling get(). This is one of the most common Java bugs in production code.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Which exceptions does the Java compiler force you to explicitly catch or declare with throws?

      
      
      

        
        
        
          
          A
          
All exceptions — Java always enforces handling

        
        
        
        
        
        
Java does not force handling for every exception. Unchecked runtime exceptions are not
compiler-enforced.

        
        
        
        
          
          B
          
Checked exceptions — subclasses of Exception that are NOT RuntimeException (e.g., IOException, SQLException)

        
        
        
        
        
        
        
        
          
          C
          
Unchecked exceptions — RuntimeException and its subclasses (e.g., NullPointerException)

        
        
        
        
        
        
Unchecked exceptions can be caught, but the compiler does not force callers to catch or declare
them.

        
        
        
        
          
          D
          
Only exceptions you define yourself

        
        
        
        
        
        
Compiler enforcement is based on exception type hierarchy, not whether the exception was
user-defined.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Java forces you to handle only checked exceptions (subclasses of Exception excluding RuntimeException) because they model recoverable external failures — unchecked exceptions model programming errors. Java divides exceptions into checked (IOException, SQLException — compiler-enforced) and unchecked (NullPointerException, IllegalArgumentException — no enforcement). Checked exceptions model recoverable external failures where the caller must make a decision. Unchecked exceptions model programming errors that should not normally occur if code is correct.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
In a Java constructor, where must super(args) appear, and what happens if you omit it?

      
      
      

        
        
        
          
          A
          
Anywhere in the constructor — Java inserts it last if omitted

        
        
        
        
        
        
Java requires constructor chaining before the subclass body runs. It cannot insert super()
after other statements.

        
        
        
        
          
          B
          
It must be the FIRST statement. If omitted, Java inserts super() (the no-arg parent constructor). If the parent has no no-arg constructor, omitting it is a compile error.

        
        
        
        
        
        
        
        
          
          C
          
After field initializations (this.field = value) so the parent doesn’t overwrite them

        
        
        
        
        
        
Parent construction must happen before subclass field setup in the constructor body.
super(...) or this(...) must come first.

        
        
        
        
          
          D
          
super() is optional and only needed if you want to pass arguments to the parent

        
        
        
        
        
        
A superclass constructor is always invoked. If no explicit call is written, Java tries to insert
super(), which can fail if no no-arg constructor exists.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
super() must be the first statement; if omitted Java inserts super() automatically, but if the parent has no no-arg constructor this causes a compile error. Java requires super() or this() to be the first statement of any constructor. If you omit super(), Java inserts a no-arg super() call automatically. If the parent class has no no-arg constructor (because it only defines parameterized constructors), the implicit call fails and you get a compile error. In C++, you’d use initializer lists: Car(args) : Vehicle(make, year) { }.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Given:
Vehicle v = new Car("Toyota", 2024, 4);
System.out.println(v.describe());

Vehicle is abstract with abstract describe(). Car overrides it. Which describe() runs?

      
      
      

        
        
        
          
          A
          
Vehicle.describe() — the reference type is Vehicle, so the compiler uses Vehicle’s version

        
        
        
        
        
        
The reference type controls what methods are legal to call, but the runtime object type controls
which overridden implementation runs.

        
        
        
        
          
          B
          
Car.describe() — Java uses dynamic dispatch: the actual runtime type determines which method runs, regardless of the reference type

        
        
        
        
        
        
        
        
          
          C
          
Compile error — you cannot call an abstract method through a reference

        
        
        
        
        
        
Calling an abstract method through a superclass reference is legal when the actual object is a
concrete subclass implementing it.

        
        
        
        
          
          D
          
A ClassCastException at runtime — the abstract method cannot be invoked

        
        
        
        
        
        
No cast is needed to dispatch an overridden method. Dynamic dispatch is the normal Java method
call behavior.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
Java dispatches methods based on the runtime type, not the reference type — unlike C++ where you must explicitly mark methods virtual to get this behavior. Java’s method dispatch is virtual by default — unlike C++ where you must add the virtual keyword. The JVM looks at the actual object type (Car) at runtime, not the declared reference type (Vehicle). This is polymorphism: one line of code (v.describe()) calls the right implementation for each object in a heterogeneous collection. @Override confirms this intent at compile time.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Expert
      
      
      
Arrange the lines to implement a generic Pair<A, B> class with a static swap method that returns a Pair<B, A>.

      
      

        
Drag lines into the solution area in the correct order (some items are distractors that should not be used). Keyboard: focus a line and press Space or Enter to move it between the bank and the answer area. Use Arrow Up or Arrow Down to reorder within the answer area.
        

        
↓ Drop here ↓
        

        

          Check Order
          Reset
        
      
      

      

        Correct order:

        
          
          public class Pair<A, B> {
    private A first;
    private B second;
    public Pair(A first, B second) { this.first = first; this.second = second; }
    public A getFirst()  { return first; }
    public B getSecond() { return second; }
    public static <X, Y> Pair<Y, X> swap(Pair<X, Y> p) {
        return new Pair<>(p.getSecond(), p.getFirst());
    }
}
          
        
      
      
      

        
Explanation
        
The static swap method must declare its own type parameters <X, Y> independent of the class’s <A, B>, and return Pair<Y, X> to actually flip the types. The class declares two type parameters <A, B>. The swap method introduces its own parameters <X, Y> (independent of the class’s A, B) and returns Pair<Y, X> — types flipped. The distractor Pair<X, Y> as the return type doesn’t actually swap anything. The raw Pair distractor loses all type safety. (Java’s private is class-scoped, so direct access to p.second from inside Pair itself would actually compile — but the accessor getSecond() is preferred for consistency with the surrounding code style.)

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Intermediate
      
      
      
Arrange the lines to define a Shape interface and a Circle class that correctly implements it.

      
      

        
Drag lines into the solution area in the correct order (some items are distractors that should not be used). Keyboard: focus a line and press Space or Enter to move it between the bank and the answer area. Use Arrow Up or Arrow Down to reorder within the answer area.
        

        
↓ Drop here ↓
        

        

          Check Order
          Reset
        
      
      

      

        Correct order:

        
          
          public interface Shape {
    double getArea();
    double getPerimeter();
}
public class Circle implements Shape {
    private double radius;
    public Circle(double radius) { this.radius = radius; }
    @Override
    public double getArea() { return Math.PI * radius * radius; }
    @Override
    public double getPerimeter() { return 2 * Math.PI * radius; }
}
          
        
      
      
      

        
Explanation
        
Circle implements Shape (not extends) is required; interface methods have no body, and @Override confirms the implementation matches the contract. Interfaces use implements, not extends (that’s for class inheritance). Interface method declarations have no body — just a signature and semicolon. The implementing class provides all methods. @Override is optional but strongly recommended — the compiler verifies you’re overriding a real method, catching typos. The abstract class distractor would work but be the wrong choice for a pure contract with no shared state.

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Advanced
      
      
      
Arrange the lines to define a checked exception, declare it in a method, and handle it in calling code.

      
      

        
Drag lines into the solution area in the correct order (some items are distractors that should not be used). Keyboard: focus a line and press Space or Enter to move it between the bank and the answer area. Use Arrow Up or Arrow Down to reorder within the answer area.
        

        
↓ Drop here ↓
        

        

          Check Order
          Reset
        
      
      

      

        Correct order:

        
          
          class InsufficientFundsException extends Exception {
    public InsufficientFundsException(String msg) { super(msg); }
}
public boolean withdraw(double amount) throws InsufficientFundsException {
    if (amount > balance) { throw new InsufficientFundsException("Insufficient funds"); }
    balance -= amount;
    return true;
}
try {
    account.withdraw(1000.0);
} catch (InsufficientFundsException e) {
    System.out.println("Error: " + e.getMessage());
}
          
        
      
      
      

        
Explanation
        
A checked exception must extend Exception (not RuntimeException) and the method must declare throws, forcing callers to handle it or propagate it. Checked exceptions extend Exception (NOT RuntimeException). The throws declaration in the method signature is mandatory — callers that don’t catch or re-throw it won’t compile. The distractor extending RuntimeException would make it unchecked, removing compiler enforcement. Omitting throws from the signature is a compile error as soon as the method body contains throw new InsufficientFundsException(...).

        Next Question
      
    
    
    

      
      
      
        Difficulty:
        Expert
      
      
      
[Interleaving: Interfaces + Collections + OOP] You’re designing a Course class. It needs:

  
A way for other classes to enroll/drop students without knowing the internal storage
  
Fast O(1) lookup for isEnrolled(String name)
  
No duplicate enrollments


Which two decisions together best achieve these goals?

      
      
      

        
        
        
          
          A
          
Use a List<Student> internally; expose it via getStudents() so callers can call .contains()

        
        
        
        
        
        
Exposing getStudents() leaks the storage decision and makes duplicate prevention a caller
problem. It also gives List lookup costs.

        
        
        
        
          
          B
          
Define an Enrollable interface with enroll(), drop(), isEnrolled() — use LinkedHashSet<Student> internally for O(1) lookup with no duplicates and insertion order preserved

        
        
        
        
        
        
        
        
          
          C
          
Use HashMap<String, Student> internally; make all fields public since that simplifies the API

        
        
        
        
        
        
A HashMap may support lookup, but public fields destroy the information-hiding requirement and
expose representation directly.

        
        
        
        
          
          D
          
Use ArrayList<Student> internally and expose a getStudents() getter returning the full list

        
        
        
        
        
        
Returning the full ArrayList makes callers depend on the internal collection and gives linear
lookup plus manual duplicate checks.

        
        
        
      
      
      

        Correct Answer:
        
      
      
      

        
Explanation
        
An Enrollable interface hides the storage decision, and LinkedHashSet provides O(1) lookup, deduplication, and insertion order — fulfilling all three requirements at once. The interface (Enrollable) decouples the contract from the implementation — callers depend on behavior, not on how students are stored (information hiding). LinkedHashSet<Student> gives O(1) contains(), automatic deduplication, and insertion-order iteration. ArrayList would require O(n) duplicate checks. Exposing getStudents() leaks the storage decision — if you switch collections, callers break.

        Next Question
      
    
    
  

  

    

      
Workout Complete!
      

        Your Score: 0/18
      
      

      

        Restart Workout
        Review Incorrect Questions