Java

---

Dark Mode

Show Highlights

Audio Clips

This is a reference page for Java, designed to be kept open alongside the Java Tutorial. Use it to look up syntax, concepts, and comparisons while you work through the hands-on exercises.

New to Java? Start with the interactive tutorial first — it teaches these concepts through practice with immediate feedback. This page is a reference, not a teaching resource.

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:

Keyword	Why
public	The JVM must be able to call it from outside the class
static	No instance of the class is created before main runs
void	Returns nothing; use System.exit() for exit codes
String[] args	Command-line arguments, like C++’s argv

Quick mapping from Python and C++:

Feature	Python	C++	Java
Entry point	if __name__ == "__main__":	int main() (free function)	public static void main(String[] args) (class method)
Typing	Dynamic (x = 42)	Static (int x = 42;)	Static (int x = 42;)
Memory	GC + reference counting	Manual (new/delete) or RAII	GC (generational)
Free functions	Yes	Yes	No — everything lives in a class
Multiple inheritance	Yes (MRO)	Yes	No — single class inheritance + interfaces

// 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:

Primitive	Size	Default	Wrapper
byte	8-bit	0	Byte
short	16-bit	0	Short
int	32-bit	0	Integer
long	64-bit	0L	Long
float	32-bit	0.0f	Float
double	64-bit	0.0	Double
char	16-bit	'\u0000'	Character
boolean	1-bit	false	Boolean

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++:

Modifier	Class	Package	Subclass	World
private	✓	✗	✗	✗
(none) = package-private	✓	✓	✗	✗
protected	✓	✓	✓	✗
public	✓	✓	✓	✓

⚠ 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.

Secret to Hide	Example	Why
Data representation	int[] vs ArrayList vs database	Storage format may change
Algorithm	Bubble sort vs quicksort	Optimization may change
Business rules	Grading thresholds, capacity limits	Policy may change
Output format	CSV vs JSON vs text	Reporting needs may change
External dependency	Which API or library to call	Vendor may change

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:

	C++	Python	Java
Mechanism	Pure virtual functions / abstract class	Duck typing (no enforcement)	interface keyword, compiler-enforced
Multiple inheritance	Yes (virtual base classes)	Yes (MRO)	A class can implement multiple interfaces
Default methods	No	No	Java 8+: default methods can have implementations

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:

	Interface	Abstract Class
Methods	Abstract (+ default in Java 8+)	Abstract AND concrete
Fields	Only static final constants	Instance fields allowed
Constructor	No	Yes
Inheritance	implements (multiple OK)	extends (single only)
Use when…	Unrelated classes share behavior	Related classes share state + behavior

Generics

Generics: Not C++ Templates

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

Feature	C++ Templates	Java Generics
Mechanism	Code generation (monomorphization)	Type erasure (single shared implementation)
Runtime type info	Yes — vector<int> ≠ vector<string>	No — List<String> = List<Integer> at runtime
Primitive types	Yes — vector<int> works	No — must use List<Integer>
new T()	Yes	No — type is unknown at runtime

// 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:

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.

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.

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.

// 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.

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.

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.

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.

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) { }.

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.

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.

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:

1. scores.get("Bob") — "Bob" is not a key, so HashMap.get() returns null (not 0, not an exception)
2. int grade = null — auto-unboxing expands this to null.intValue()
3. 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.

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:

1. Catch it: try { calc.divide(10, 0); } catch (CalculatorException e) { ... }
2. 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.

// 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.

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.

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.

Workout Complete!

Your Score: 0/15

Come back later to improve your recall!

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.

[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.

[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.

[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().

[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.

[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.

[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.

[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).

[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.

[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.

[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().

[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.

[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.

[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.

[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.

[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.

Workout Complete!

Your Score: 0/15

Come back later to improve your recall!

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.

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));

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().

What does this code print?

Integer x = 200;
Integer y = 200;
System.out.println(x == y);
System.out.println(x.equals(y));

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 ==.

What happens at runtime when this code executes?

Integer count = null;
int n = count;

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.

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?

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.

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

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.

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?

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.

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

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.

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

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).

This code does not compile. Why?

public boolean isStringList(List<?> list) {
    return list instanceof List<String>;
}

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.

[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)

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.

What is the bug in this code?

Map<String, Integer> scores = new HashMap<>();
scores.put("Alice", 95);
int grade = scores.get("Bob");

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.

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

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.

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

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) { }.

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?

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.

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):

↓ Drop here ↓

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. Direct field access p.second is illegal since fields are private.

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):

↓ Drop here ↓

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.

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):

↓ Drop here ↓

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(...).

[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?

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.

Workout Complete!

Your Score: 0/18