Review and Revision of Modules 8 to 14

# Review and Revision of Modules 8 to 14

This lecture is a consolidation revision that revisits the core building blocks introduced across Modules 8–14 — inheritance and polymorphism, abstract types and interfaces, exception handling, generics and collections, concurrency, object copying, enumerations, and type bounds. Rather than introducing one new algorithm, it threads a single design habit through every topic: declare a clear contract at the top, implement it concretely below, and protect shared resources when many participants act at once. Use this preamble as a roadmap: skim the 16 concept blocks in order, note how each remedial diagram re-uses the previous one, and keep the Exam Guidance Summary as a checklist while reading.

26.1 Inheritance and Method Categories

26.1.1 What Inheritance Means and Why It Matters

An inheritance — a mechanism where a child class receives properties of a parent class — is one of the core ideas in object oriented programming. A parent class — also called a base class or super class — defines data members and member functions. A child class — also called a derived class or sub class — can have one or more siblings, each inherits from the same parent, yet each adds its own detail.

Think of a family recipe book. The parent book contains basic dough, sauce, and baking steps shared by all pizzas. Each child book copies all those base recipes automatically, then adds its own toppings page — pepperoni for one child, paneer for another. You never re-copy the dough recipe. That is exactly how class inheritance reuses code.

A child can reach the data members of the parent when they are marked public or protected. It can also reach the member functions of the parent. The same idea appears everywhere: interfaces build on inheritance, generic collections rely on class relationships, the Java object model is a hierarchy whose root is Object, and even multi-threading uses inheritance when a class extends Thread.

From the view of the derived class, the base exposes three categories of methods:

1. Constructors — special methods that build an object. A derived constructor can call a parent constructor by using the keyword super. If the parent has several constructors, the derived constructor selects one by matching the number and type of arguments. In code, super(arguments) appears as the first line of the derived constructor. The call with the right argument list chooses which overloaded parent constructor runs; without an explicit super(...) the compiler inserts super() to call the no-argument parent constructor.

1. Overridden functions — methods whose name, return type, and argument list already exist in the parent and are re-declared in the child. From a function of the derived class you can reach the parent version by prefixing with super.

1. Normal functions — any other methods defined in the base that are not constructors and not overridden. You call them directly by name from the derived class, no prefix needed.

In a diagram, draw a vertical chain with Grandparent at the top, Parent in the middle, and Child at the bottom, each boxed. Arrows point upward labeled extends. Inside each box list the declared methods. Mark constructors with a special symbol, overridden methods with a shared color across levels, and normal methods without marking. A second small diagram shows BankAccount at the top with balance and accountNumber, and CheckingAccount below with an extra overdraftLimit — illustrating how only the new field must be declared.

Real-world context: extending a framework class to reuse common behaviour is routine. In banking software a base BankAccount holds balance, accountNumber, deposit() and withdraw(). A CheckingAccount extends it, reuses those fields and methods, and adds overdraftLimit and processCheck(). In application frameworks a base Thread or Exception class is extended the same way — the child reuses threading or error-handling machinery while adding domain logic. In the Java collections framework the same inheritance principle lets ArrayList and LinkedList share the Collection contract while storing data differently.

26.1.2 Method Overriding in Detail

An overridden method — a method where child and parent share the same name and the same type signature — is central to inheritance. The type signature in this setting includes the method name, the return type, the number of arguments, and the type of each argument. When the signature matches, we say the child overrides the parent method. For overriding the name, the return type, the count of parameters and each parameter type must all line up; a single difference turns the pair into overloaded methods, not overridden ones.

Consider a parent class ABC with a method getData(). A child class XYZ extends ABC and also declares getData() with the same return type and the same argument count and types. That is an overridden method. If you create an object x of type XYZ and write x.getData(), the call resolves to getData() as defined in the derived class XYZ, not the base version. Inside the derived version, if you need the base behaviour, you write super.getData().

A second visual: draw ABC above XYZ with a box for each. List getData(): void inside both boxes in the same color to signal overriding. Draw a solid arrow from x.getData() at the call site down to XYZ.getData(), and a dashed super arrow from inside XYZ.getData() back up to ABC.getData(). Label the signature components — name, return void, parameter list () — along the arrow to reinforce the check.

26.1.3 Worked Example — Multi-Level Inheritance with print()

Setup: three levels — Grandparent at the top, Parent in the middle, Child at the bottom. Each declares the same method:

class Grandparent {
    public void print() { System.out.println("grandparent"); }
}
class Parent extends Grandparent {
    public void print() { System.out.println("parent"); }
}
class Child extends Parent {
    public void print() { System.out.println("child"); }
}

Each print() is an overridden method because name, return type void, and argument list () are identical at all three levels. The hierarchy is Child extends Parent extends Grandparent, arrows pointing upward to the parent.

A second walk-through in the same style uses getData() in ABC and XYZ described above, with XYZ x = new XYZ(); x.getData(); routing to the child version unless super.getData() is used inside XYZ. The diagram for this duplicate example mirrors the print() chain: XYZ box below ABC, arrow down from x.getData() to the child block, super arrow up inside the child.

26.2 Dynamic Method Dispatch, Runtime Polymorphism and Upcasting

26.2.1 Runtime Polymorphism Explained

A dynamic method dispatch — the rule by which a call to an overridden method is resolved at runtime rather than at compile time — is the mechanism behind runtime polymorphism — polymorphism where the actual method executed depends on the object, not the reference type, during execution. A related term is upcasting — when a reference variable of the parent type points to an object of the child type. Together they give the "one interface, multiple behaviours" power of object-oriented design.

In Java, you can write Parent obj; on the left side and obj = new Child(); on the right side. The left side type is Parent, the right side object is Child. This is allowed and is called upcasting. The variable obj is a parent reference, the object it points to is a child object. The assignment compiles because every Child is-a Parent, so a parent-typed variable can safely refer to any child object. The opposite — Child c = new Parent(); — does not compile without a cast, because not every parent is a child.

When you later call obj.show(), which show() runs? The answer is determined by the object, not by the variable type. If Child overrides show(), the child's show() runs even though the variable is declared as Parent. That choice is made at runtime, after the program starts, when the actual object type is known. The compiler only checks that Parent declares a show(); the JVM at runtime follows the object's virtual table to the overriding version.

Think of it like this: the label on the box says Parent, but the content inside the box is a Child. When you ask to play or show, the content decides what happens. This separation is why inheritance supports flexible code where a parent reference can work with many child types.

A visual makes the mechanism clear: draw two columns. Left column shows the reference variable obj : Parent as a small labeled box with an arrow pointing to an object bubble on the right labeled Child object. Inside the Child bubble write the overridden method show() -> "child show" in bold, and inside the Parent shape behind it write show() -> "parent show" in light gray. The call arrow obj.show() goes from the variable to the bubble's table, then a selection arrow highlights the child's version. Annotate the arrow "runtime lookup — object type wins."

Real-world and domain connection: Runtime polymorphism is the reason a single method like void render(Shape s){ s.draw(); } can draw circles, rectangles, and triangles without if branches — each Shape child overrides draw() differently, and s may point to any of them. In the Java collections framework a single Collection<BankAccount> accounts list can store SavingsAccount and CheckingAccount objects; iterating and calling acc.calculateInterest() dispatches to the right child each time. Server code, GUI event handling, and payment processing all lean on a parent reference handling many child types through the same call site.

26.2.2 Worked Example — Parent Reference to Child Object

Code:

class Parent {
    void show() { System.out.println("parent show"); }
}
class Child extends Parent {
    void show() { System.out.println("child show"); } // overridden
}
public class Test {
    public static void main(String[] args) {
        Parent obj = new Child(); // upcasting: parent reference, child object
        obj.show(); // calls Child.show()
    }
}

Visual reinforcement: Draw the timeline of the call. At compile time, a checkpoint labeled "compiler: Parent has show()? YES — compile succeeds." At runtime, a second checkpoint labeled "JVM: object is Child — use Child.show()." Connect the two with a dashed line showing that runtime corrects any label-only guess.

26.3 Abstract Classes

26.3.1 Definition and Purpose

An abstract class — a restricted class that cannot be used to create direct objects — works as a template. It can declare methods without giving them a body and can also define concrete methods. An abstract method — a method declared with the keyword abstract and no implementation — states what a sub class must do, not how. It is a responsibility handed downward: the parent decides the name and signature, the child decides the body.

You mark a class with the keyword abstract, for example abstract class ABC. You mark a method similarly, for example abstract void getData(); and abstract void showData();. Inside an abstract class you cannot create objects directly with new ABC(); instead you create a concrete sub class that extends the abstract class and provides bodies for all abstract methods. Only then can you instantiate the sub class.

An abstract class enforces a hierarchy: the declaration lives at the top, the definitions live below. It ensures that related classes share symmetry and promise the same set of operations. That symmetry is valuable in large codebases — every account type, every shape type, every handler type promises the same entry points, so calling code can rely on them uniformly.

Visual: draw a pyramid. At the apex put the abstract box ABC with two entries marked "abstract — no body": getData() and showData(). Below the apex draw two concrete boxes DerivedA and DerivedB, each with solid versions of getData() and showData() filled in. Draw arrows upward labeled extends. Cross out an illustration of new ABC() with a red X and label "compiler error — cannot instantiate abstract," while showing new DerivedA(10) with a green check.

Real-world and domain connection: The Java library uses abstract classes such as java.awt.Component and java.util.AbstractList as shared skeletons that concrete widgets and lists flesh out. In banking code an abstract class BankAccount { abstract void calculateInterest(); void deposit(double amt){ balance+=amt; } } forces every account type to supply its interest math while reusing common deposit logic — the exact symmetry the lecture enforces with getData() and showData().

26.3.2 Worked Example — ABC with Two Abstract Methods

abstract class ABC {
    abstract void getData();
    abstract void showData();
}
class DerivedA extends ABC {
    DerivedA() { } // zero-argument constructor, does blank initialization
    DerivedA(int a) { this.a = a; } // one-argument constructor, stores value in field a
    void getData() { /* body that reads or sets data */ }
    void showData() { /* body that prints data */ }
    int a;
}

A second check: draw memory slots. For new DerivedA(10), show a heap object with field a = 10 and two method-pointer slots getData -> DerivedA.getData and showData -> DerivedA.showData. For the hypothetical new ABC(), draw a crossed-out box explaining that those two slots have no target — hence the instantiation ban.

Common confusion: students sometimes try to instantiate the abstract parent directly. That fails. You can only hold a parent reference to a child object, similar to upcasting, but the object itself must be of a concrete child. Another trap is forgetting that DerivedA's two constructors are not inherited — they must be written explicitly if you want both the zero-argument and the int form.

26.4 Interfaces and Multiple Inheritance

26.4.1 Interface Basics

An interface — a contract that lists method declarations without bodies (except for default and static methods treated later) — defines what implementing classes must do. A concrete class that implements an interface must provide bodies for all declared methods. Think of the interface as a checklist of method signatures; implementing it is signing a contract to tick every box.

Key syntax contrast: a class extends another class using extends, but a class implements an interface using implements. An interface can extend other interfaces using extends. Java does not allow a class to extend more than one class, so multiple inheritance of classes is blocked. Multiple inheritance through interfaces is allowed: a single class can implement several interfaces, combining their contracts.

Hierarchy practice: think of BankAccount as a class, Bank as an interface. CheckingAccount can be written as class CheckingAccount extends BankAccount implements BankInterface. The diagram with two interfaces on top and a single class below that implements both illustrates this.

The related idea of association between classes describes how objects relate, and the chart shown links multiple interfaces to a single implementing class to highlight that a class can promise several sets of behaviour at once.

A visual detail preserved from the slides: interfaces are often drawn with the <<interface>> stereotype and dashed implements arrows (open triangle, dashed line) versus solid extends arrows (open triangle, solid line). The distinction makes clear at a glance which relationship is class inheritance and which is contract implementation.

Real-world and domain connection: The Java standard library recovers multiple inheritance through interfaces in practice. class ArrayList implements List, RandomAccess, Cloneable, and Serializable at once, each interface adding a separate promise. In domain code a CheckingAccount extends BankAccount implements Bank, Printable promises both money operations and the ability to print a statement; a PatientRecord extends Person implements Serializable, Comparable combines persistence and ordering. Choosing interfaces over multiple class inheritance keeps the type system clean.

26.4.2 Worked Example — Multiple Inheritance via Interfaces

interface Bank { void deposit(double amt); void withdraw(double amt); }
interface Printable { void print(); }
class BankAccount { double balance; }
class CheckingAccount extends BankAccount implements Bank, Printable {
    public void deposit(double amt) { balance += amt; }
    public void withdraw(double amt) { balance -= amt; }
    public void print() { System.out.println(balance); }
}

A second illustration from the slides links several standard interfaces (Serializable, Comparable, Cloneable) to one class box; the lesson repeats: one class can promise several sets of behaviour, each interface contributes its own set, and the implementing class covers the union.

In industry, the CheckingAccount pattern appears as class SavingsAccount extends Account implements InterestBearing, Insurable, or class DataNode extends Node implements Serializable, Cloneable. Each implements adds a cross-cutting capability while the single extends preserves the primary is-a lineage.

26.5 Default and Static Methods in Interfaces

26.5.1 Default Methods as Fallback Implementations

Before default methods, any method in an interface had no body, and every implementing class had to define it. A default method — a method in an interface that carries the keyword default and includes a body — provides an implementation directly inside the interface without breaking existing classes that implement the interface. It allows adding new methods to interfaces without forcing every old implementing class to change. The body is a fallback: if a class does not override it, the interface's version runs; if the class does override, the class's version is preferred.

Example layout as shown: interface Printable declares void print(); as a normal abstract declaration with no body. Right next to it, highlighted in red, is default void show() { System.out.println("default show"); }. The keyword default appears before the return type void, the method name is show, and the body prints.

Usage with a class:

interface Printable {
    void print();
    default void show() { System.out.println("default show"); }
}
class Trial implements Printable {
    public void print() { System.out.println("trial print"); }
}
public class Test {
    public static void main(String[] args) {
        Trial t = new Trial();
        t.print(); // calls Trial.print()
        t.show();  // no show() in Trial, so falls back to Printable's default show()
    }
}

Walk-through summary: Trial implements Printable and must define print() because it is abstract. It does not define show(), yet t.show() compiles and runs because Printable supplies a default show(). If later Trial adds its own show(), calls to t.show() will prefer the class version over the default. If you delete the show() method from Trial (when it exists), you must also remove any direct call expectation, but the program still compiles due to the fallback. A common question discussed is "what happens when show() is removed from Trial?" Nothing breaks for the outer interface implementation, because the default remains.

A visual: draw Printable as a dashed box with two compartments — upper says print() — abstract (no body), lower says show() — default with body. Draw Trial as a solid box with one compartment print() — concrete and a dashed outline where show() would be, connected with an arrow labeled "fallback -> interface default" that only fires when the class compartment is empty.

26.5.2 Static Methods in Interfaces

A static method in an interface — a method marked static inside an interface, accessed via the interface name — behaves like a static method in a class. A static variable is a class variable; a static method is reached through the class or interface name, not through an object. Unlike default methods, a static interface method is never inherited by the implementing class and never participates in polymorphism.

If ABC is a class with static void getData(), you call it as ABC.getData(). Similarly, if Printable is an interface with static void show(), you call it as Printable.show();. No object of Printable is needed.

Example:

interface Printable {
    static void show() { System.out.println("static show"); }
}
 // call site
Printable.show();

Normal instance methods in an interface remain abstract; default and static methods are the two forms that can carry a body inside an interface. Visual contrast: draw three interface compartments — print() abstract, show() default (instance, inherited), helper() static (type, not inherited). Draw an instance call arrow from a Trial object to the default compartment and a static call arrow directly on the interface box for helper(), showing that the implementing class box never receives a dashed inheritance arrow for the static member.

26.5.3 Industry Note

Real-world: Java 8 introduced default methods to let APIs evolve. Collections interfaces added new default methods without breaking the many classes that already implemented them. Classic examples are Collection.forEach, List.sort, Map.getOrDefault, and Iterable enhancements — each was added as a default so the thousands of existing List and Map implementations kept compiling without modification. Static interface methods similarly provide namespaced helpers like List.of() or Comparator.comparing(). Together they let large ecosystems extend contracts over time while preserving backward compatibility, the exact fallback lesson examined above.

26.6 Nesting of Classes and Interfaces

26.6.1 Forms of Nesting

A nested class — a class defined inside another class — and a nested interface — an interface defined inside another class or interface — allow logical grouping in one place for readability and maintainability. Grouping says these types are coupled in purpose and will not be reused far apart; it also controls visibility and namespace so Printable.Showable is directly a sub-contract of Printable.

Four combinations are possible:

• A class inside a class: class ABC { class XYZ { } } — XYZ is an inner class inside ABC.
• An interface inside an interface.
• A class inside an interface.
• An interface inside a class.

Nested members can access all members of the outer class, including private data members and methods, because the inner member is considered part of the outer object. This privileged reach is the practical gain beyond mere grouping — an inner class can manipulate the outer's private state without exposing it.

Example with two interfaces, one nested:

interface Printable { // outer interface
    void print(); // belongs to outer
    interface Showable { // inner interface
        void show(); // belongs to inner
    }
}
class Trial implements Printable {
    public void print() { System.out.println("print"); }
    // implementing Printable does NOT force implementing Showable's show()
}
// To require show(), you would write:
class Trial2 implements Printable.Showable {
    public void print() { System.out.println("print"); } // if also implementing outer?
    public void show() { System.out.println("show"); }
}

Clarification as discussed: outer interface is Printable with void print(), inner interface is Showable with void show(). A class Trial that writes implements Printable must define print() but need not define show(), because show() lives in the inner interface. Removing show() from Trial causes no problem in this setup because it was never required. Conversely, a class that writes implements Printable.Showable would be forced to define show() from the inner interface, and if it also implements the outer, it would need both.

Visual: draw a large outer rectangle Printable with print() inside. Draw a smaller rectangle Showable nestled in the upper-right corner of the outer, containing show(). Draw class Trial below with a dashed arrow to the outer rectangle only, and class Trial2 with a dashed arrow to the inner rectangle. Label the dashed arrows implements Printable and implements Printable.Showable. This spatial nesting reinforces that namespacing is enclosure, not inheritance.

26.6.2 Three Kinds of Inner Classes

Nested classes appear in three practical forms:

1. Member inner class — a non-static class defined directly inside an outer class as a member, with a name and full access to the outer's instance state. It behaves like a field that is itself a class. You create it as Outer outer = new Outer(); Outer.Inner in = outer.new Inner(); and it holds an implicit reference to the enclosing outer object.

1. Anonymous inner class — a class defined without a name, typically right where it is instantiated, useful for one-off implementations. It is written as Printable p = new Printable(){ public void print(){...}}; — no class name, no reuse elsewhere, created and used at the single expression site. Common for short listener or Runnable overrides.

1. Local inner class — a class defined inside a method or block, visible only within that scope. It cannot have a public modifier and its instances capture only final or effectively final locals. Example: void process(){ class Helper { void run(){...}} Helper h = new Helper(); } — Helper vanishes outside process().

These forms appear in detail in the supplemental slides with full code, intentionally skipped in the review due to time constraints but recommended for self-study. The key property remains: an inner class is part of the outer class, so it can reach private fields of the outer. For revision, sketch three panels: panel 1 shows a class box with a smaller class box beside a field labeled "member — has a name, needs outer.new Inner()"; panel 2 shows a new expression with a curly block and the label "anonymous — no name, at the new site"; panel 3 shows a method box with a tiny class inside labeled "local — lives only inside the method."

Visual plus self-study cue: compare the instantiation forms side-by-side in prose. Member: Outer out = new Outer(); Inner in = out.new Inner(); in.use(); — two steps, needs an outer instance. Anonymous: Printable p = new Printable(){ public void print(){...}}; p.print(); — one expression, no name. Local: inside void m(){ class Local{ ... } Local l = new Local(); } — the class name Local is unknown to any other method. This table makes the "where it lives" distinction concrete.

Real-world and domain connection: Member inner classes power builders such as Map.Entry as an inner view of Map, or LinkedList's internal Node class. Anonymous inner classes historically implemented event listeners — button.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e){ ... } }) — before lambdas. Local inner classes collect short helpers inside a single complex method without polluting the public API. Recognizing which nesting form is in use lets readers predict where the name is visible and whether an outer instance is implicitly carried.

26.7 Exception Handling — Try, Catch, Finally and Hierarchy

26.7.1 What an Exception Is

An exception — an event where a program that compiled without problems nevertheless stops in an abnormal way during execution — must be handled to keep the program alive. Compilation checks syntax and types; exceptions report runtime conditions that syntax alone could not prevent, such as a zero divisor arriving from user input, a missing file, or an out-of-range index.

A textbook trigger uses three variables:

int a = 10;
int b = 0; // supplied by the user
int c = a / b; // statement that may generate an exception

The spoken description is "$c=a÷b$" where $a=10$ and $b=0$. Mathematically this is $c=\frac{a}{b}$ with $b=0$. Division by zero gives infinity in theory, but in Java integer division by zero throws an ArithmeticException and terminates execution at that line abnormally. Whatever statements follow this line never execute. That abnormal termination point is the exception.

Real-world: unexpected input, file not found, network drop, or wrong array index all generate exceptions. A good program anticipates suspect statements and prepares handling paths, because unhandled exceptions freeze user sessions, leave files open, or roll back a half-written transaction.

Visual: draw a vertical sequence of boxes representing program lines. Box a=10, Box b=0, Box c = a/b highlighted in red with a branch labeled exception thrown, and Box println(c) grayed out with an X labeled "skipped." An arrow from the red box jumps to a catch handler box to show the alternative handled path.

26.7.2 Try, Catch, Finally and Hierarchy

Java provides three constructs for handling:

• try — encloses the statement you suspect may generate an exception. Writing that statement inside a try block prepares the program to deal with trouble rather than crash.
• catch — follows a try block and handles the exception thrown from inside the try. Whatever exceptions the try throws are caught in corresponding catch blocks.
• finally — differs from both. A catch runs only if an exception occurs. A finally always runs, whether an exception occurred or not. It is the guaranteed cleanup phase for closing files, releasing locks, or flushing buffers.

Example structure:

try {
    int c = a / b; // risky statement c = a/b with b==0
} catch (ArithmeticException e) {
    System.out.println("divide by zero");
} catch (Exception e) {
    System.out.println("other exception");
} finally {
    System.out.println("cleanup");
}

Hierarchy visual: draw an inverted tree. Top node Throwable. Two children Error and Exception. Under Exception branch to IOException (checked branch) and RuntimeException (unchecked branch). Under RuntimeException draw ArithmeticException and ArrayIndexOutOfBoundsException. Annotate checked versus unchecked, and add a note that ArithmeticException is the descendant that catches $b=0$ for integer division, while IOException is never triggered by division.

Worked comparison — no handling versus handling:

• Class with no handling: the division line throws, the following System.out.println never runs; the program ends at the exception line.
• Class with handling: the risky division is placed inside try, two catch blocks are supplied — one for ArithmeticException (the specific divide-by-zero case) and one for Exception (a broader catch). Whichever matches handles the problem, and the program continues. The finally block runs in both success and failure paths.

Hierarchy: an exception hierarchy — a tree of exception types — sits under Throwable. At the top, Throwable is the ultimate parent. Below it, Exception is one of the root classes for all checked and runtime exceptions that programmers interact with. Specific exceptions such as ArithmeticException and ArrayIndexOutOfBoundsException extend deeper. Using Exception as a catch type catches many subtypes, which is why ordering matters: specific catches first, generic Exception later.

Mathematical view: for integers, the operation $c=\frac{a}{b}$ with $b=0$ is not a valid integer result, hence the exception. The division law in integer arithmetic requires the divisor to be non-zero for the quotient to be defined; the hardware signals a fault when that precondition is broken, and Java maps the fault to ArithmeticException rather than returning a bogus integer. The verbal description "a divided by b where b is zero" maps directly to the failing Java line.

26.8 Throw versus Throws, Checked versus Unchecked, User-Defined Exceptions

26.8.1 Checked versus Unchecked

A checked exception — a condition checked during compile time — must be declared or handled at compile time; examples include IOException. An unchecked exception — a condition that appears only at runtime — falls under RuntimeException; examples include ArithmeticException and ArrayIndexOutOfBoundsException. The distinction is not about severity but about where the Java language insists you acknowledge the risk.

In the hierarchy, Exception splits into checked branches (direct subclasses of Exception other than RuntimeException) and the unchecked branch rooted at RuntimeException. IOException is a classic checked example: if a method can throw it, the compiler forces handling. RuntimeException branches contain errors that the compiler does not force you to handle upfront but that can still crash a running program.

A visual table lets the difference pop: columns Type, Root, Compile-time handling required?, Examples. Row 1: Checked, under Exception but not RuntimeException, Yes — catch or throws`, IOException. Row 2: Unchecked, under RuntimeException, No — compiler allows silence, runtime may still throw, ArithmeticException, ArrayIndexOutOfBoundsException, InvalidBoxDimensionException. The tree diagram highlights the fork point immediately below Exception`.

26.8.2 Throw versus Throws

A throw clause — throw used to generate an exception — creates an exception object at a precise line. It is used for exception classes only. If you as a user decide that "whenever a value is less than zero, that should count as an exception" — even though the computer sees no error — you can enforce it with throw. A throws clause — throws used to forward an exception — states that a method may forward an exception to its caller when it cannot handle it itself. It is a forwarding mechanism, while throw is a generating mechanism. Specifically, if a method throws a checked exception, its signature must declare throws CheckedException, otherwise compilation fails.

Example to contrast:

// throw generates
if (a < 0) throw new IllegalArgumentException("a < 0"); // generation

// throws forwards
void readFile() throws IOException { // forwarding to caller
    // code that may throw IOException internally
}

A visual clarifies the roles: draw a vertical call stack with main at the top calling readFile() which calls new FileReader. Place a red throw new IOException lightning bolt inside FileReader. Draw a dashed throws IOException arrow on the readFile() frame edge pointing upward, labeled "forwarding — no handling here." At the main frame draw a catch (IOException) box that absorbs the bolt. Label the two spots: inside the body (throw) versus on the signature line (throws). This picture preserves the lecture's line-level distinction.

26.8.3 Worked Example — User-Defined Exception InvalidBoxDimensionException

Goal: treat an invalid box size as an exception the user defines, not the language's built-in one — negative or zero dimensions are not a Java error, but the application decides they should abruptly stop construction just as a language exception would.

Step 1 — define the exception. It extends RuntimeException, making it unchecked (so no mandatory throws declaration everywhere, as noted that it specifically extends the runtime branch):

class InvalidBoxDimensionException extends RuntimeException {
    InvalidBoxDimensionException(double value) {
        System.out.println("Box instance with invalid dimension: " + value);
    }
}

Constructor receives a double value — the invalid dimension — and prints Box instance with invalid dimension plus the value. Real production code would also call super("Box instance with invalid dimension: " + value) to carry the message into the throwable's message field and optionally store the value as a field, but the lecture's defined form prints directly from the constructor for brevity.

Step 2 — define Box that uses it:

class Box {
    double length, width, height;
    Box(double length, double width, double height) throws InvalidBoxDimensionException {
        if (length <= 0 || width <= 0 || height <= 0) {
            throw new InvalidBoxDimensionException(length <=0 ? length : width <=0 ? width : height);
        }
        this.length = length;
        this.width = width;
        this.height = height;
    }
    double area() { return 2*(length*width + width*height + height*length); } // example helper
}

Walk-through recap: Box has three double fields length, width, height. Its constructor declares throws InvalidBoxDimensionException — the forwarding clause. Inside, it checks if (length <= 0 || width <= 0 || height <= 0). If any dimension is less than or equal to zero, it executes throw new InvalidBoxDimensionException(...), passing the offending value to the constructor which prints the message. This is the generation point using throw. If all dimensions are valid, the constructor assigns them and optionally computes area that can be printed via area().

Step 3 — handling at creation site:

try {
    Box b = new Box(-2, 5, 3); // invalid length triggers throw
} catch (InvalidBoxDimensionException e) {
    System.out.println("handled invalid box");
}

Real-world: user-defined exceptions model domain errors — negative box, negative balance, duplicate enrollment, expired ticket — where the language sees no failure but the application does. Choosing extends RuntimeException keeps the API lightweight (no forced declaration at every call site) while still letting callers wrap construction in try/catch where they want to recover; choosing extends Exception makes the checked contract louder and forces callers to decide at compile time.

26.9 Generics — Parameterized Types

26.9.1 The Idea of Generics

A generic — also called a parameterized type — lets a class or method work with a type supplied in brackets, written as ClassName<T>. The type parameter T is a type variable that is replaced throughout the class execution by whatever concrete type you pass. The syntax was shown as class Identity<T> { T obj; ... } and the type variable T must be followed consistently inside the class.

If you set T to String, then every T inside the class behaves like String: the field obj is a String, the constructor argument is a String, and the return type is a String. If on the next execution you set T to Long, then every T becomes Long: the field is a Long and so on. The class body does not change, only the substituted type changes.

A visual contrast helps: draw Identity<T> as a template box with three blanks T obj, Identity(T obj), T getObj(). Duplicate the box twice, coloring one blue labeled T=String with every T rewritten as String, and one orange labeled T=Long with every T rewritten as Long. An arrow from the template to each colored duplicate says "substitution at new time." Mark a red X on id1 = new Identity<Long>("hello") with the label "compile error — Long slot cannot accept String."

Real-world and domain connection: The Java collections framework depends on this very mechanism — ArrayList<String> versus ArrayList<Integer>, HashMap<K,V> versus Pair<T,U> — one library definition serves every type safely. In application code the same principle appears as Response<T>, Cache<K,V>, or Result<T,Error> where the surrounding logic (caching, retry) is reusable while the payload type changes per call.

26.9.2 Single Type Parameter — Identity<T> Walk-Through

class Identity<T> {
    T obj;
    Identity(T obj) { this.obj = obj; }
    T getObj() { return obj; }
}

Usage:

Identity<Long> id1 = new Identity<Long>(123L); // T is Long, value 123L
System.out.println(id1.getObj()); // prints 123

Identity<String> id2 = new Identity<String>("hello"); // T is String
System.out.println(id2.getObj()); // prints hello

Steps summary: for id1, the generic argument is Long, so T everywhere becomes Long, the stored object is a Long with value 123. Printing via getObj() shows the long value. For id2, T is String, the object is a String "hello", and printing shows the string. The same class handles both type families without duplication.

Visual: draw a table with rows Declaration, Field type, Constructor, Stored value, getObj() return, Prints. Fill row for id1: Identity<Long>, Long, Identity(Long), 123L, Long 123L, 123. Row for id2: Identity<String>, String, Identity(String), "hello", String "hello", hello. The alignment makes clear that the column shapes match across the two rows — only the concrete name differs.

26.9.3 Multiple Type Parameters — T and U

A generic with multiple parameters — e.g., class Container<T, U> — takes two placeholders. In the example, one parameter is T treated as String and the other is U treated as Integer. Objects can then be created in either order.

class Pair<T, U> {
    T first; U second;
    Pair(T first, U second) { this.first = first; this.second = second; }
    void print() { System.out.println(first + " " + second); }
}
Pair<String, Integer> i1 = new Pair<String, Integer>("hello", 10);
Pair<Integer, String> i2 = new Pair<Integer, String>(10, "hello");
i1.print(); // hello 10 — String then Integer for i1
i2.print(); // 10 hello — Integer then String for i2 (swapped)

Explanation: for i1, T maps to String and U maps to Integer, so creation prints string first then integer. For i2, the arguments are reversed: T is Integer and U is String, so the printed order is integer then string. Both use the same generic definition but behave differently based on the order of type arguments passed.

A second view reinforces the pattern: draw Pair<T,U> as a generic railcar with two compartments labeled T: first and U: second. Show railcar i1 with String:hello in the T compartment and Integer:10 in the U compartment. Show railcar i2 with Integer:10 in the T compartment and String:hello in the U compartment. The railcar shape is identical; only the color label on each compartment swapped, yet the order of compartments (first then second) stayed fixed — compartment position determines which logical argument sits where.

Real-world: collections such as ArrayList<T> and HashMap<K,V> are generics. HashMap<String,Integer> mirrors Pair<String,Integer> for the key-value sense, while HashMap<Integer,String> mirrors the swapped form. Parameterized methods and parameterized types throughout the library work on the same substitution principle, and the two-parameter Pair pattern recurs as Map.Entry<K,V>, BiFunction<T,U,R>, or Result<Value,Error>.

26.10 Collections Framework

26.10.1 Array versus List and the Need for a Uniform Interface

Different data structures — ways of organizing a group of data — store the same values differently. An array stores elements in consecutive blocks of memory for the same data type, giving fast index access but fixed size. A list (linked variant) stores elements at scattered memory locations connected through links, growing flexibly but with different cost to reach an element. Other structures include map, tree, set, but arrays and lists illustrate the split.

The objective of both array and list is the same — hold a group of data — but the storage mechanism differs. Without a common interface, code that adds to an array would look different from code that adds to a linked list. The collections framework provides a single, uniform way: call an add method and pass the element, no matter whether the underlying store is an array or a linked list. That convenience avoids handling implementation details of each structure.

Visual: draw two memory diagrams side by side. Left: a horizontal row of five adjacent boxes labeled al[0]..al[4] with an arrow add(5) needing to grow the row if full. Right: five scattered boxes Node1..Node5 each with a field next arrow hopping to the next box, with add("C") splicing by rewiring the tail pointer. Below both, draw a thin horizontal bar labeled Collection<T> — add(T e) that spans across the two diagrams, emphasizing the single call that covers both representations.

Real-world and domain connection: The same uniformity carries beyond arrays and lists to Set, Map, Queue, and Deque. Calling add, remove, contains, or isEmpty on a HashSet, TreeSet, or PriorityQueue uses the same vocabulary even though a hash table, a red-black tree, and a heap back them respectively. That is the framework's promise: learn one vocabulary, apply it to every aggregate, and swap underlying storage without rewriting calling code.

26.10.2 Collection Interface and Core Methods

A collection — declared as the generic interface Collection<T> — specifies the type of objects the collection will hold, analogous to the Identity<T> generics seen before. It declares core methods that every collection supports. General methods include boolean add(T e), boolean addAll(Collection<? extends T> c), void clear(), boolean contains(Object o), boolean isEmpty(), and int size(), plus many more. These are the shared methods available whether the actual store is an array, list, map, tree, or list iterator.

Related views are the Collection interface itself that enables working with a group of objects, and the List, Set, and Map specializations that refine the contract. Draw the interface diamond: Collection<T> at the top, List<T> and Set<T> beneath it, Map<K,V> beside them as a cousin, with ArrayList and LinkedList beneath List and HashSet beneath Set. Label the central bar add(T e), clear(), contains(Object), isEmpty(), size() to show the shared core, then annotate the outer branches with their refinements (get(index) for List, containsKey for Map).

Real-world and domain connection: The uniform core is what lets library code accept Collection<BankAccount> accounts and process any concrete shape — list, set, or queue — without knowing which backing structure the caller chose. Utility code such as Collections.sort(List<T>) or Collections.binarySearch operates through the interface; switching from ArrayList to LinkedList happens at construction, and the rest of the calls stay identical. The next two examples make that sameness concrete with real add calls.

26.10.3 Worked Example — ArrayList (Unparameterized)

import java.util.ArrayList;
class ArrayListTest {
    public static void main(String[] args) {
        ArrayList al = new ArrayList(); // raw, no type parameter
        al.add(10);        // Integer 10
        al.add("hello");   // String
        al.add(3.14f);     // Float
        al.add(true);      // Boolean
        System.out.println(al);
    }
}

Steps summary: create al as a raw ArrayList from java.util with no type parameter. Without a parameter, the list accepts heterogeneous elements: integer 10, string "hello", float 3.14f, boolean true together in the same list, even though such mixing is rarely desired in production. Printing the list shows all four. To add at a specific position, the overloaded add(index, element) can be used. You do not adjust array internals; you simply call add.

Visual: draw the backing Object[] inside ArrayList as four adjacent slots at scattered conceptual addresses but stored contiguously in the backing array, each slot holding a reference arrow to a different object bubble — Integer, String, Float, Boolean. Label the vertical size counter size=4. Below, draw a LinkedList node chain that would look scattered and uses next arrows instead, reinforcing that al.add needs no caller-side array management in either implementation.

26.10.4 Worked Example — LinkedList<String> (Parameterized)

import java.util.LinkedList;
class LinkedListTest {
    public static void main(String[] args) {
        LinkedList<String> l1 = new LinkedList<String>();
        l1.add("F");
        l1.add("B");
        l1.add("C"); // additional adds
        System.out.println(l1); // prints [F, B, C] order of insertion
    }
}

Steps summary: create l1 as LinkedList<String> — now the parameterized type is constrained to String. Calls to add("F") then add("B") insert at the end by following links rather than shifting a contiguous block. The linked version stores elements at scattered locations linked together (elements 1, 2, 3 connected via links). Printing l1 shows [F, B, C]. The crucial point: the background handling of array storage versus linked storage is hidden; the caller uses the same add method in both examples. Removing the type parameter reverts to raw heterogeneous behaviour; adding <String> restricts to strings only.

Visual comparison: keep the left panel's ArrayList with its contiguous backing array, and the right panel's LinkedList as scattered nodes with next arrows. Put a single horizontal banner labeled Collection.add(T e) across both panels, with identical l1.add("F") text above each panel, showing verbatim call text on divergent internals and identical printed result order [F, B, C] beneath.

In industry, the same uniform methods extend to adding elements to a tree, set, or map. Collections provide the standard interface so developers do not rewrite insertion logic per structure. In practice a producer method declared as void fill(Collection<String> c) can be called with either new ArrayList<String>() or new LinkedList<String>() without change — the receiving side only calls c.add(...).

26.11 Multithreading — Thread Creation and Life Cycle

26.11.1 What a Thread Is

A process — a running program such as P1 — can contain several threads — lightweight paths of execution, for example T1, T2, T3 belonging to P1 — that work on shared data. Multithreading — having multiple threads within a single process — is the technique where those threads cooperate on the same data held by P1. In the first two demonstrations, only a single thread existed; now multiple threads share common data. The process provides the shared address space (heap, statics); each thread provides its own stack, program counter, and scheduling state.

A thread in Java is built in two ways: (1) by extending the Thread class, (2) by implementing the Runnable interface. Thread is a predefined class. Runnable is an interface. Both approaches funnel through the same entry point that the threading system actually invokes.

A central method appears in both approaches: public void run(). Whatever line of action you want a thread to execute must be written inside run(). That method keeps the thread active; when the code inside run() is entered, the thread has work to do. Never call run() directly expecting a new thread — call start() instead, as explained below.

Visual: draw P1 as a large rounded box containing three smaller threads T1, T2, T3 each with its own tiny stack icon, plus a shared heap region labeled "shared data." Draw two construction branches to the left: branch A shows class ABC extends Thread with an arrow obj.start() -> ABC.run(); branch B shows class ABC implements Runnable plus new Thread(a) wrapping, then t.start() -> ABC.run(). Both branches meet at a single public void run() box to stress convergence.

Real-world and domain connection: Extending Thread appears in simple demos, while implementing Runnable (or submitting to an ExecutorService) dominates production code because it separates the task definition from the threading machinery. Web servers use one Runnable per request sharing the same Cache object, media pipelines use parallel threads sharing a frame buffer, and batch jobs use thread pools sharing a queue — all are the P1 containing T1,T2,T3 working on shared data the lecture names.

26.11.2 Thread States

Threads move through four states:

• New state — a thread object has been created but not yet started.
• Running state — after start() is invoked, if the processor is free the thread is allocated CPU and executes its task; while running, it performs the code in run().
• Waiting state — the thread pauses for a reason, for example purposely sleeping via sleep(milliseconds) or waiting for input/output. When the sleep timer expires or the I/O completes, the thread returns to running.
• Terminated state — also called dead. When the task finishes and the closing curly bracket of public void run() is reached, after all tasks inside run() have executed, the thread moves to terminated. A terminated thread cannot be restarted.

Transitions: new Thread() creates new state. thread.start() attempts to move to running if CPU is free. Thread.sleep(1000) moves to waiting for 1000 milliseconds. Completion of run() moves to terminated.

Visual: draw a state diamond. Top node New with arrow new Thread() arriving. Down-right arrow labeled thread.start() (if CPU free) to node Running with small run(){...} inset and a self-loop labeled "executing." Down-left arrow from Running to Waiting labeled sleep(millis) / wait() / I/O, with return arrow back labeled sleep expires / notify() / I/O done. Final downward arrow from Running to Terminated (Dead) labeled } end of run(). Cross out a dashed arrow attempting to return from Terminated to New with label "illegal — cannot restart."

Real-world and domain connection: Health checks and monitoring panels report Thread.State such as TIMED_WAITING while a pool thread sleeps between jobs; thread-pool frameworks recycle Runnable tasks across a fixed set of long-lived threads rather than restarting dead threads. The promised flow "control goes back" after run() is the observable dispatch loop: a completed run() signals completion, returns the thread to the pool or to TERMINATED, and lets dependent consumers proceed.

26.11.3 Worked Example — Extending Thread

class ABC extends Thread {
    public void run() {
        System.out.println("thread is running");
    }
}
public class Test {
    public static void main(String[] args) {
        ABC obj = new ABC(); // ABC is-a Thread, thread has no separate name beyond object reference
        obj.start(); // calls Thread.start(), which in turn causes run() to execute
    }
}

Visual supplement: draw two vertical stacks side by side. Left stack is main thread calling ABC obj = new ABC() then obj.start(). Right stack appears at the start() call-out as a new column labeled ABC thread entering run(). Shade the moment start() returns in main while run() continues independently in the new column — illustrating that start() does not block.

26.11.4 Worked Example — Implementing Runnable

class ABC implements Runnable {
    public void run() {
        System.out.println("thread is running");
    }
}
public class Test {
    public static void main(String[] args) {
        ABC a = new ABC();
        Thread t = new Thread(a); // wrap runnable in a Thread
        t.start(); // start() from Thread, control goes to ABC.run()
    }
}

Steps summary: here ABC implements Runnable via implements, so it must define public void run(). To start a thread, you wrap the runnable object a inside a Thread object t = new Thread(a). Calling t.start() again delegates to run() in ABC. The printed line is the same. Both approaches — extending Thread versus implementing Runnable — eventually funnel through public void run() as the active entry point.

A comparative table cements the dual forms: column 1 header Extend Thread, column 2 header Implement Runnable. Row Declaration: class ABC extends Thread versus class ABC implements Runnable. Row Has start()?: yes, inherited versus no — wrap in new Thread(a). Row Create: ABC obj = new ABC() versus ABC a = new ABC(); Thread t = new Thread(a). Row Launch: obj.start() -> ABC.run() versus t.start() -> ABC.run(). Row Can also extend another class?: no versus yes. Both rows end with the same printed line thread is running.

26.12 Thread Priorities and First Multi-Thread Example

26.12.1 Priority Values

Every thread has a priority — an integer between 1 and 10 that hints to the scheduler which thread should run first. The default priority is 5. Moving toward 10 means higher priority, first chance to execute compared with a low priority near 1. A greater number represents a higher priority in the Java multithreading environment.

Methods getPriority() and setPriority(int newPriority) read and adjust the value. Example adjustment as shown: for a thread someT, reduce priority by 2 from default 5 to 3 using code similar to someT.setPriority(someT.getPriority() - 2);. For another thread factT, increase by 2 from 5 to 7 using factT.setPriority(factT.getPriority() + 2);. After adjustment, factT with priority 7 is favoured over someT with priority 3.

Visual: draw a horizontal bar from 1 to 10. Mark ticks at 1 MIN, 5 NORM (default), 10 MAX. Place someT dot at 3 with an arrow rightward labeled -2 from 5, and factT dot at 7 with arrow rightward labeled +2 from 5. Shade the region between 3 and 7 showing 7 > 3 favored. Add a caution icon with caption "hint, not lock — scheduler may reorder."

Real-world and domain connection: Priority hints are used in servers and interactive systems where responsiveness matters more than background work — the UI/event-dispatch thread may hover near 7-8 while file-indexing or sync threads linger at 3-4. Media servers elevate audio threads to reduce dropouts, while game loops demote asset-loading workers. The win is latency for the high-priority path, not throughput; excessive priority gaming can starve low-priority housekeeping and is mitigated by executors with fair queues rather than raw priority tweaks.

26.12.2 Worked Example — Sum and Factorial Threads

class SumThread implements Runnable {
    public void run() {
        int sum = 0;
        for (int i = 1; i <= 5; i++) sum += i;
        System.out.println("sum = " + sum); // printed one by one during execution
        // control returns to caller after loop finishes
    }
}
class FactThread implements Runnable {
    public void run() {
        int fact = 1;
        for (int i = 1; i <= 5; i++) fact *= i;
        System.out.println("fact = " + fact);
    }
}
public class Test {
    public static void main(String[] args) {
        Thread someT = new Thread(new SumThread());
        Thread factT = new Thread(new FactThread());
        someT.setPriority(someT.getPriority() - 2); // 5 -> 3
        factT.setPriority(factT.getPriority() + 2); // 5 -> 7
        someT.start();
        factT.start();
    }
}

Walk-through reiterated: two runnable classes SumThread (computes sum 1+2+...+n) and FactThread (computes factorial). Threads someT and factT wrap them. Priorities are set as above. Starting both lets the scheduler decide order, but factT at 7 is more likely to run before someT at 3, although the exact interleaving remains up to the operating system. The run() bodies show the pattern "what is written in public void run, like sum should be printed one by one, and when execution is done, control goes back" — the loop prints stepwise, then the thread terminates after reaching the end of run().

A timeline diagram makes interleaving visual: horizontal time axis, two swim lanes someT (priority 3) and factT (priority 7). Mark launch points start() with vertical dashed lines, then shade CPU usage bars where each thread occupies the CPU, with factT's bar slightly ahead but with a footnote "order influenced by priority, decided by OS — bars may swap." Annotate the compute phase loop accumulates feeding into a final println(sum=15) or println(fact=120) box, and a terminal dot labeled Terminated.

26.13 Thread Synchronization — Monitors, Critical Sections and Synchronized Access

26.13.1 Critical Section and Monitor

When two or more threads work on a shared resource, uncontrolled access leads to wrong results. A critical section — also called a mutually exclusive block or shared-resource section — is code that only one thread should execute at a time. If thread T1 already executes the section, thread T2 should not enter until T1 leaves. Thread synchronization is the coordination that enforces this, achieved with the concept of a monitor.

A monitor — an object used as a mutually exclusive lock — works as follows: T1 enters, it owns the monitor and acquires a lock. Any other thread like T2 attempting to enter the locked monitor is suspended until the first thread exits the monitor. When T1 exits, the monitor is freed and T2 can acquire it, enter under lock, execute, then free the monitor again. The critical section stays protected by holding and freeing the monitor.

Visual: draw a door labeled monitor of shared CallMe target. T1 is inside the room executing call(msg), holding a key labeled lock. T2 and T3 wait outside the door with a sign "suspended." When T1 sleeps inside (eyes closed, but still gripping the key), the others remain outside because the key is not released. Only when T1 steps out and hands back the key does T2 receive it and enter.

Real-world and domain connection: Monitors and critical sections prevent corrupted transfers in banking (synchronized on the shared Account during withdraw), duplicate seat bookings in airline reservations, and garbled structured logs when ten request threads share one file writer. In producer-consumer pipelines the shared queue's put/take methods are the canonical critical sections, each synchronized on the queue's monitor even though the payload differs.

26.13.2 Worked Example WITHOUT Synchronization — CallMe, Caller, Sync

class CallMe {
    void call(String msg) {
        System.out.print("[" + msg); // e.g., [hello
        try { Thread.sleep(1000); } catch (InterruptedException e) {}
        System.out.println("]"); // ]
    }
}
class Caller implements Runnable {
    CallMe target; String msg; Thread t;
    Caller(CallMe target, String msg) {
        this.target = target; this.msg = msg;
        t = new Thread(this); // create thread taking this runnable via this operator
        t.start(); // start immediately; will enter public void run
    }
    public void run() {
        target.call(msg); // call target.call with message
    }
}
class Sync {
    public static void main(String[] args) {
        CallMe target = new CallMe(); // one shared object, name target repeated
        Caller ob1 = new Caller(target, "hello");
        Caller ob2 = new Caller(target, "java");
        Caller ob3 = new Caller(target, "programming");
    }
}

Steps without synchronized restated: CallMe.call(String msg) prints "[" + msg, then sleeps 1000 ms, then prints ]. Caller implements Runnable; its constructor initializes target, msg, creates new Thread(this) and calls start(). When started, control reaches public void run() which does target.call(msg).

In Sync.main, one shared CallMe target is created. Three Caller objects ob1, ob2, ob3 are created with messages "hello", "java", "programming". Ideal sequential expectation is [hello], then [java], then [programming] each on its own line.

What actually happens without synchronization: ob1 prints [hello and sleeps 1000 ms. The processor should not stay idle, so the scheduler gives the CPU to ob2, which prints [java and sleeps; then ob3 prints [programming and sleeps. When the sleep timers expire, the closing ] characters appear interleaved, yielding a garbled order observed on the system. The text repeats The name of the object is target many times, stressing that all three callers share the same target reference, making the race obvious. The sequence of execution is decided by sleep timing and scheduler, not by creation order.

A timeline makes the interleaving visible: horizontal time lane per caller with events T: open [msg, box sleep 1000, event close ]. Without synchronization the three open events cluster early, the three sleep boxes overlap, and the three close events cluster late, interleaving as open1 open2 open3 close? close? close?. Add a dotted monitor absence label across the top explaining why the sleep window invites entry.

26.13.3 Fix 1 — Synchronized Method

To restrict the race, prefix the method definition with synchronized:

class CallMe {
    synchronized void call(String msg) {
        System.out.print("[" + msg);
        try { Thread.sleep(1000); } catch (InterruptedException e) {}
        System.out.println("]");
    }
}

Everything else remains the same. By marking call as synchronized, the monitor associated with the CallMe object is held for the entire execution of the method, even if the current thread sleeps and the processor could be given to another. The current thread finishes printing the closing bracket before another thread can enter call. The scheduler will wait even if waiting means keeping the CPU idle for 1000 ms. Output becomes ordered: [hello] then [java] then [programming], each message bracketed correctly.

A visual contrast helps: keep the same three lane timeline but shade the synchronized monitor as a single roped corridor. ob1 enters and hangs a "occupied" sign that stays during sleep, ob2 and ob3 wait at the door instead of walking in; after ob1 exits the door, ob2 passes in with the same sign, then ob3. The idle-CPU-while-holding habit is annotated: "sleep keeps the lock."

26.13.4 Fix 2 — Synchronized Statement (Block)

Instead of marking the method, synchronize at the call site:

class Caller implements Runnable {
    // ...
    public void run() {
        synchronized(target) { // synchronized keyword with object
            target.call(msg);
        }
    }
}

Here the synchronized(target) block tracks synchronization. One by one, whichever thread reaches the block first owns the monitor of target; other threads wait until that thread finishes and frees the monitor. The rest of the logic stays identical, and the printed sequence becomes correct with proper brackets.

Real-world: synchronization prevents corrupted transfers, duplicate bookings, or garbled logs when many threads share counters, files, or sockets. The two forms — synchronized method and synchronized(object) { ... } block — are the standard tools.

A second comparative figure: show two code panels. Left panel highlights synchronized before void call in CallMe. Right panel highlights synchronized(target){ around target.call(msg); in Caller.run(). Draw a shared monitor circle labeled target with arrows from both panels pointing to the same circle, annotating "Fix 1 locks the callee, Fix 2 locks the call site — same monitor object, same correctness."

26.14 Java Object Model — Object Cloning, Shallow versus Deep Copy

26.14.1 The Root Object and the Need for Cloning

In the Java object model, Object is the universal parent class. Every class implicitly or explicitly descends from Object, so every object inherits toString(), equals(), hashCode(), and clone(). Cloning concerns copying an object so that the copy has a distinct identity but equal content — the clone's fields hold the same values as the original, yet the two objects live at different addresses. That distinct address means later mutation of one does not disturb the other (deep for mutable referenced parts) — unlike alias assignment which leaves a single address behind two names.

Example hierarchy: class ABC declares two data members, String name and double salary (later also Date hireDate for shallow/deep contrast). Objects created: E1 with name = "Mike" and salary = 35000, E2 with name = "Smith" and salary = 40000, sharing the same class.

If a new object A3 should hold the same values as E1 ("Mike", 35000), writing A3 = E1; does not create a separate entity. In memory, suppose address 1000 stores the fields "Mike" and 35000, and E1 points to 1000. The assignment makes A3 also point to 1000; both references share the same address, no separate copy exists. Changing one would affect the other.

To get a genuine separate copy, we need object cloning. The Java mechanism for this is the marker Cloneable interface cooperating with Object.clone().

Visual: draw two heap boxes. Box at 1000 with "Mike" and 35000. Two arrows enter it labeled E1 and A3 after A3 = E1. Next panel labeled "cloning" shows two boxes: box 1000 with E arrow, and new box 1001 with cloned arrow, each containing "Mike" and 35000 but at distinct addresses, illustrating distinct identity with equal content.

26.14.2 Worked Example — Cloneable and clone()

class ABC implements Cloneable {
    String name;
    double salary;
    Date hireDate; // from Date class, mutable

    public Object clone() throws CloneNotSupportedException {
        return super.clone(); // call Object.clone()
    }
}
public class Test {
    public static void main(String[] args) throws CloneNotSupportedException {
        ABC E = new ABC(); E.name = "Mike"; E.salary = 35000;
        ABC clone_A = (ABC) E.clone(); // creates distinct object with same content
        // Now E and clone_A have same name/salary but different identities
    }
}

Walk-through: ABC implements Cloneable. The method public Object clone() throws CloneNotSupportedException is required; it calls super.clone(), which asks Object to create a field-by-field copy. That call returns an object that is cast and assigned to clone_A. After cloning, E and clone_A contain the same content ("Mike", 35000) but their addresses differ, their references differ, their identities differ. This is the duplicated object versus the original object.

The main method shows Clone A calling A.clone() to obtain clone_A. The assignment separates identity while keeping equality of field values. Cost visual: heap panel after cloning shows E -> 1000: { name->"Mike", salary 35000, hireDate->D0 } and clone_A -> 1001: { name->"Mike" (shared pointer), salary 35000 (own copy), hireDate->D0 (shared pointer pending deep fix) }. Label primitive salary as value-copied, name as shared-immutable, hireDate as shared-mutable (bug pending).

26.14.3 Shallow Copy versus Deep Copy

The clone produced by super.clone() alone is a shallow copy — the top object's fields are copied, but referenced objects are not duplicated; only the reference pointers are copied. Thus class references remain shared. With shallow copy, E and cloned have same primitive salary value but stored separately (changing one does not affect the other). However name and hireDate in both objects still point to the same String object and the same Date object in memory. Their object references are not changed; only a shallow copy is created. For String this sharing is safe because String is immutable and cannot be directly changed. For Date it is not safe, because mutating the date via one object would be visible through the other.

To create a deep copy — a fully independent duplicate including referenced mutable objects — we copy the mutable field separately after the shallow clone:

public Object clone() throws CloneNotSupportedException {
    ABC cloned = (ABC) super.clone(); // shallow as before
    // String needs no extra work (immutable)
    // Date must be copied explicitly for deep copy
    cloned.hireDate = (Date) this.hireDate.clone(); // or new Date(this.hireDate.getTime())
    // salary already independent as primitive
    return cloned;
}
// Usage: cloned.hireDate now independent from E.hireDate
// Statement form shown as: hireDate copied from E.hireDate to clone.hireDate

Walk-through anchored to the memory diagram: start from shallow clone E:1000 and cloned:1001 with shared D0. Leave String name as shared (immutable, safe). For Date, create a separate Date object and assign to cloned.hireDate, copying value from E.hireDate to clone.hireDate. Now clone.hireDate points to a different address than E.hireDate. The salary primitive is already separate. The resulting clone is deep for the mutable part while still efficient for immutable strings.

If you mutate cloned.hireDate after deep cloning, E.hireDate stays unchanged, confirming independence. With shallow cloning alone, the mutation would leak. Heap diagrams sequence this story: panel A shows shallow alias cloned.hireDate -> D0 <- E.hireDate; panel B shows deep isolation cloned.hireDate -> D1, E.hireDate -> D0 with D0 and D1 holding equal epoch but different arrows; a caption marks "mutate Date via clone — no leak after deep" versus "leak before deep."

Real-world: cloning supports safe duplication of user profiles, configuration snapshots, or prototype patterns where a new object should start with the same state but evolve independently. In prototype frameworks each concrete product clones a registered prototype; in persistence layers a detached entity is deep-cloned so changes can be merged without corrupting the cached original. The principle proven here — hireDate copied from E.hireDate to clone.hireDate via an explicit Date.clone() or new Date(getTime()), salary automatically independent, String safely shared — guides exactly which fields to deepen in each domain copy.

26.15 Enumerated Types (enum)

26.15.1 What an Enum Is

An enum — an enumerated type with a finite set of values — restricts a variable to only those values listed in the set. It is defined with the keyword enum and is internally equivalent to a class with a private constructor and a fixed number of instances. Once the set is declared, no new element can be added at runtime; the closed set is the type's completeness.

Consider Size with values SMALL, MEDIUM, LARGE:

enum Size { SMALL, MEDIUM, LARGE }

This declaration defines a class whose instances are exactly SMALL, MEDIUM, LARGE. No other values can be used. Access is via Size.SMALL, Size.MEDIUM, Size.LARGE.

The equivalence shown makes this explicit:

class Size {
    private Size() {} // private constructor: no outside creation
    public static final Size SMALL = new Size();
    public static final Size MEDIUM = new Size();
    public static final Size LARGE = new Size();
}

Steps: a private constructor prevents creating objects outside the class. Instances are created inside the class with static final so their values never change and they are reachable via the class name (Size.SMALL). The enum keyword builds the same structure automatically.

Visual: draw two panels. Panel A shows the terse enum box enum Size { SMALL, MEDIUM, LARGE } with a lock icon on the constructor. Panel B expands to the class box with three rows SMALL: static final, MEDIUM: static final, LARGE: static final, each pointing to a heap singleton, and annotate new Size() outside with a red X labeled private. The lock and the static final together caption "compiler-enforced closed set, no runtime extension."

Real-world and domain connection: Enums appear wherever only fixed choices exist — days of week Day { MONDAY, ... }, order status OrderStatus { PENDING, SHIPPED, DELIVERED, RETURNED }, compass directions Direction { NORTH, EAST, SOUTH, WEST }, or UI theme Theme { LIGHT, DARK }. Replacing error-prone raw String or int codes with enums moves the "must be one of this set" check from a runtime if to a compile-time type error, which is exactly the inventory-safe Size.SMALL discipline illustrated.

26.15.2 Worked Example — Season with For-Each Loop

class ABC {
    enum Season { WINTER, SPRING, SUMMER, FALL }
    public static void main(String[] args) {
        for (Season s : Season.values()) {
            System.out.println(s); // prints each constant
        }
    }
}

Walk-through: enum Season holds four values WINTER, SPRING, SUMMER, FALL. ABC contains this enum and a main method with a for-each loop. Loop control variable s takes values present in Season one by one. System.out.println(s) prints each constant as the loop iterates. The order printed follows declaration order: first WINTER, then SPRING or SUMMER (discussion notes variation: first WINTER, then SUMMER, then SPRING, then FALL on one run, but declaration order governs). Once values are defined in the set, they cannot be changed; only the listed values are allowed. You cannot add a new season at runtime.

Visual: draw Season as a vertical column of four labeled islands WINTER, SPRING, SUMMER, FALL in stack order top to bottom matching declaration. Draw the for-each loop as a hopper that visits each island in top-to-bottom order, printing its label upon arrival. Label the hopper for (Season s : Season.values()) and mark the printed stream to the right as WINTER ... FALL in vertical order aligning with the islands.

Real-world: enums appear wherever only fixed choices exist — days of week, order status (PENDING, SHIPPED, DELIVERED), compass directions — giving compile-time safety over raw strings. A workflow that processes Season s can exhaustively handle the four branches without if on String typos like "Wintr"; the compiler rejects an assignment of "WINTER" the String to Season s at once, enforcing the closed set guarantee where a String Constant would only fail at runtime.

26.16 Bounded Types

26.16.1 Bounding a Generic Type

An unbounded generic — e.g., class Bound<T> where T can be String, Long, Integer, or anything — places no limits on the type argument. A bounded type — written as T extends A — restricts T to type A itself or any sub class of A. The phrase T extends A is the bound; A is the upper limit. With the bound in place, obj.displayClass() becomes safe to call because the compiler knows every allowed T is at least an A.

Why bound? Without a bound you cannot call A's methods on a T value safely, because T might be unrelated. With T extends A, the compiler knows every allowed T is at least an A and supports A's operations.

Visual: draw A at the top with a method displayClass() inside. Draw B extends A and C extends A as two children below A, each with an overriding displayClass() body. Draw an unrelated island String far away. Shade the region covering A, B, C as the bounded range labeled T extends A — admissible, and mark String outside the shade labeled "outside — rejected." Label the Bound<T> box holding T obj with an arrow to obj.displayClass() annotated "safe because bound guarantees method exists."

Real-world and domain connection: Bounded generics appear as class SortedList<T extends Comparable<T>> where the bound ensures compareTo exists, method <T extends Number> void process(T value) where the bound guarantees numeric operations, or Spring's Repository<T extends Entity> where persistence operations assume getId(). Each bound says "this generic expects at least these promises from its type argument, or it will not compile."

26.16.2 Worked Example — Bound<T extends A> with A, B, C Hierarchy

Hierarchy setup:

class A {
    void displayClass() { System.out.println("inside class A"); }
}
class B extends A {
    void displayClass() { System.out.println("inside subclass B"); } // overrides
}
class C extends A {
    void displayClass() { System.out.println("inside subclass C"); } // overrides
}
class Bound<T extends A> {
    private T obj; // field of generic type T bounded by A
    Bound(T obj) { this.obj = obj; }
    void doRunTest() { obj.displayClass(); } // safe because T extends A guarantees displayClass
}

Steps reiterated: A defines void displayClass(). B extends A and overrides the same method, printing "inside subclass B". C extends A and overrides similarly, printing "inside subclass C". Each is a sub type or child of A. Bound declares T extends A, holds a private T obj, receives a T via constructor, and offers doRunTest() that calls obj.displayClass().

What T can be? Directly A, or any sub class — so B or C. The statement "this type can directly be A or any of the subclasses of A" captures the rule. Creating new Bound<A>(new A()) is allowed and stores an A. Creating new Bound<B>(new B()) is allowed and stores a B; calling doRunTest() dispatches to B's version and prints "inside subclass B". Similarly new Bound<C>(new C()) prints "inside subclass C". The hierarchy discussion repeats Bound definition and emphasizes the bound line T extends A as the limiting keyword.

What is forbidden? Passing String, Long, Integer, or any type unrelated to A. The attempt new Bound<String>(new String("x")) fails to compile because String does not extend A. The bound restricts type arguments that can be used as parameterized types to those related to A — either A itself or its children B and C, nothing beyond.

A variant phrase used is "restricting types that can be used as type arguments in a parameterized type" — exactly what bounded types achieve. This lets a generic class safely use methods of the bound (here displayClass) on the generic field.

A table sharpens the admissibility rule: columns Instantiation, Bound check, doRunTest prints. Row 1: Bound<A>(new A()), A extends A — allowed, inside class A. Row 2: Bound<B>(new B()), B extends A — allowed, inside subclass B. Row 3: Bound<C>(new C()), C extends A — allowed, inside subclass C. Row 4: Bound<String>(new String("x")), String NOT extends A — compile error, no execution — rejected before call.

Real-world: bounded generics appear as class SortedList<T extends Comparable<T>> or method <T extends Number> void process(T value) where the bound ensures numeric or comparable behaviour is present.

Exam Guidance Summary

The review covers modules 8 to 14: inheritance and overriding, dynamic dispatch and upcasting, abstract classes, interfaces with default and static methods, nesting, exception handling with try / catch / finally, throw versus throws plus checked versus unchecked and a user-defined InvalidBoxDimensionException, generics with single and multiple parameters, the collections framework, multithreading life-cycle and priorities, synchronization via monitors (synchronized method and synchronized block), object cloning with shallow versus deep copy, enumerated types, and bounded types (T extends A).

For the assessment, plan for conceptual questions ("define overriding", "explain dynamic method dispatch", "distinguish abstract class from interface"), code-tracing questions (given Parent obj = new Child(); obj.show(); which method runs; given CallMe with three callers predict interleaving with and without synchronized), and short write-code asks (write a user-defined exception that triggers when a dimension is <= 0; write a generic identity class Identity<T>; write Bound<T extends A>). When a question involves try / catch / finally, place the risky statement inside try, handle specific exceptions first, and remember that finally always executes. For cloning, state implements Cloneable, override clone() with super.clone() and handle CloneNotSupportedException, then explain shallow versus deep handling of mutable fields like Date versus immutable String. For enums, know that enum Season { WINTER, SPRING, SUMMER, FALL } is accessed as Season.WINTER and iterated with for (Season s : Season.values()). For generics and bounded types, be explicit about the substitution rule and the exact bound T extends A limits.

Time constraints prevented covering each slide in full depth; referenced supplemental slides contain additional worked programs for inner classes (member, anonymous, local) and fuller collection demonstrations — reviewing them with the code shown adds clarity. Write assumptions in simple form and present any table or step sequence as shown, since that style aids evaluation.

Key Industry Applications

Real-world: inheriting from base account or framework classes to reuse fields and behaviour; using parent references to handle many child types through the same call site via runtime polymorphism; modelling contracts with abstract classes and interfaces, and recovering multiple inheritance by implementing several interfaces (e.g., a checking account that extends a bank account and implements a bank contract); evolving published interfaces with default methods so old implementers keep working without re-coding, and exposing utility operations as InterfaceName.staticMethod(); grouping related types with nested classes and interfaces for maintainability, with member, anonymous, and local inner classes as common patterns; handling runtime failures with try / catch / finally, generating domain errors with throw and forwarding checked errors with throws, modelling domain exceptions such as invalid dimensions; building type-safe reusable containers with generics (Identity<T>, Pair<T,U>, ArrayList<T>, LinkedList<T>, Map<K,V>) and restricting them with bounded types (T extends A, T extends Comparable, T extends Number); accessing every data structure uniformly through the collections framework core methods add, clear, contains, isEmpty, size; creating concurrent programs with Thread or Runnable plus public void run(), managing life-cycle states new → running → waiting (via sleep) → terminated, tuning with priorities 1–10 (default 5) and coordinating shared resources with monitors, synchronized methods, and synchronized blocks to avoid interleaving; duplicating state safely with Cloneable and clone() / super.clone(), applying deep copying for mutable fields like Date while leaving immutable String shared; restricting values to a finite safe set with enum such as Size.SMALL or Season.

In Java practice, multithreading, collections, generics, exception handling, cloning, and enums appear together in production services — a concurrent LinkedList of BankAccount tasks pulled by Thread pool workers that handle IOException via throws, duplicate snapshots via clone() for audit, and iterate Season or Size enums for reporting. The habit threading every section is the same one the preamble named: declare the contract (abstract/interface/Collection<T>/enum/T extends A), implement it exactly once per concrete shape, and guard the shared path (synchronized/try/finally) when many actors converge.