Java Object Model, Type System, Cloning and Generics

# Java Object Model, Type System, Cloning and Generics

24.1 The Object Class — Root of the Java Inheritance Hierarchy

24.1.1 Definition and Position in the Hierarchy

Every class in Java, whether it is a predefined library class or a class you write yourself, sits under one common ancestor. That ancestor is the Object class — the topmost class in the hierarchy, the root from which every other class descends directly or indirectly. When you write class Person { } without an explicit extends clause, the compiler treats it as class Person extends Object. If you later write class Employee extends Person, the chain is Employee -> Person -> Object. There is no Java class that escapes this chain. The class lives in java.lang, which is the default package. You never write import java.lang.Object.

Because Object sits at the very top, every method declared in Object is automatically available in every Java class without any import or explicit inheritance. The practical payoff is simple: a framework method that accepts Object x can call x.toString() or x.hashCode() and it will compile for any argument, because the保证 exists at the language level. You can keep the inherited version as it is, or you can provide your own version that overrides the inherited one.

A useful mental check is the class header expansion:

class Person { }                          // compiler reads: class Person extends Object
class Employee extends Person { }         // chain is Employee -> Person -> Object
Object o = new Person();                  // legal: Person is a subtype of Object
Object arr = new int[10];                 // legal: array types are subtypes of Object

Visual intuition: picture a vertical hierarchy diagram. At the top is a box labeled java.lang.Object. Directly below it are two columns: on the left, your classes Person and Employee stacked; on the right, library classes like String and ArrayList. Horizontal arrows for extends point upward to the parent, and the single converging point at the apex is always Object. The takeaway is that there is exactly one apex, so common behavior can live once and be shared everywhere.

24.1.2 Methods of Object Available to All Classes

A point that avoids later confusion: hashCode() does not give you a street address you can dereference. It gives a compact integer summary of where the object lives, so two objects that live at different places will normally show two different hash codes, while two references that alias the same place show the same hash code. The contract is directional: if x.equals(y) is true, then x.hashCode() == y.hashCode() must be true; the reverse need not hold, because collisions are allowed.

Real-world connection: the universal root is why logging frameworks can declare void log(Object msg) and collections can declare HashSet<Object>. The framework calls msg.toString() or msg.hashCode() without knowing the concrete class. In IDE debuggers, the "Inspect" view calls toString() on whatever selection you have, because the IDE knows Object guarantees that method exists.

24.1.3 Quick Review — Class as Blueprint, Object as Instance

To set up the cloning discussion, the session revisited the first building block: a class is a blueprint or structure, and an object is an instance that fills that structure with values.

Person p = new Person();
p.name.firstName = "Smith";
p.name.lastName = "Jones";
p.address.street = "10 Park Ave";
p.address.city = "Pune";

24.2 Object Identity, Reference Assignment and Why Copying Is Not Cloning

24.2.1 What Assignment Actually Copies

A frequent early mistake is to treat = as an object copier. It is not. It copies the reference variable, not the object.

ABC A1 = new ABC();   // allocate box at 1000, A1 -> 1000
ABC A2 = A1;          // copy arrow: A2 -> 1000
ABC A3 = A1;          // copy arrow: A3 -> 1000
// also shown as myCar1 and myCar2 copying a car object — same diagram

A1.value = 99;
System.out.println(A2.value); // prints 99
System.out.println(A3.value); // prints 99

Visual intuition: draw a rectangle for the heap, place one small square inside labeled ABC @1000. Draw three dots outside labeled A1, A2, A3. Draw three arrows from each dot to the single square. The takeaway is one target, three incoming edges. Adding a fourth label A4 = A1 just adds a fourth converging arrow; the square count stays at one.

Real-world connection: aliasing shows up in business code when two service layers hold references to the same Order object. A discount applied through one reference appears in the other layer's view. Frameworks sometimes use this on purpose (a cache gives many callers the same live object), and sometimes it is a bug when independent snapshots were intended.

24.2.2 The Problem Assignment Leaves Unsolved

If your goal is two independent objects that start with the same content but can then evolve independently, assignment fails. The session stated it in direct terms: assignment creates a copy of the reference variable, not a copy of the object. To get two boxes at two addresses — say A1 at 1000 and A2 at 2000 — with the same initial field values but distinct identities, you need a different mechanism. That mechanism is cloning.

24.3 Cloning — Creating an Exact Independent Copy

24.3.1 Definition and the Three Conditions Clone Must Meet

Cloning means creating a new instance of the class of the current object and initializing all its fields with exactly the same contents as the original, but at a different identity. It is the mechanism that turns aliasing (A2 = A1 with one box at 1000) into duplication (two boxes at 1000 and 2000).

Employee E = new Employee("Smith", 35000);
Employee E2 = E.clone();
System.out.println(E == E2);                    // false — distinct boxes (condition 1)
System.out.println(E.equals(E2));               // true  — same field values (condition 2)
System.out.println(E.getClass() == E2.getClass()); // true — same class (condition 3)
System.out.println(E.hashCode() == E2.hashCode()); // usually false — hash reflects storage

Visual intuition: draw two separate rectangles side by side, left labeled X @1000, right labeled X.clone() @2000. Inside each, write the same field list: name="Smith", salary=35000. Draw a red != between the outer box addresses and a green equals==true between the inner field lists. The takeaway is same contents, different containers.

24.3.2 Requirements — Public Clone and the Cloneable Interface

Two requirements must be satisfied by any class that wants to be cloneable:

1. The class must declare a clone method that is public. The version in Object is protected, so you must widen access. Otherwise code outside the package cannot call it.
2. The class must implement the Cloneable interface. The correct Java spelling is Cloneable (you may see informal spellings like clonable). It is a marker interface — it declares no methods of its own — but its presence is the signal that Object.clone() is allowed to copy this class. Without it, a call to clone throws CloneNotSupportedException.

Because cloning can fail — for example, trying to clone an object through a reference of an unrelated class — the call to super.clone() must sit inside a try/catch for CloneNotSupportedException, or the enclosing method must declare throws CloneNotSupportedException. Both styles appeared in the lecture.

// Style A: handle inside (catch)
class Account implements Cloneable {
    public Object clone() {
        try {
            return super.clone(); // calls Object.clone, creates field-by-field copy
        } catch (CloneNotSupportedException e) {
            return null; // only reached if Cloneable was missing
        }
    }
}

// Style B: forward to caller (throws) — same call, different contract
class CloneA implements Cloneable {
    public CloneA clone() throws CloneNotSupportedException {
        Object o1 = super.clone();
        return (CloneA) o1; // cast because Object.clone returns Object
    }
}

24.3.3 Worked Examples — Clone Class A and Clone Class B

The session built two complete programs to show how the pattern is used from the caller side and how inheritance interacts with Cloneable.

class CloneA implements Cloneable {
    public CloneA clone() throws CloneNotSupportedException {
        Object o1 = super.clone();       // Object.clone creates the copy at native level
        return (CloneA) o1;              // cast from Object to CloneA
    }

    public static void main(String[] args) throws CloneNotSupportedException {
        CloneA a = new CloneA();
        CloneA cloneA = a.clone();       // cloneA is the cloned copy of a
        System.out.println(a == cloneA);          // false — different addresses
        System.out.println(a.equals(cloneA));     // true if equals is overridden, else false
        System.out.println(a.getClass() == cloneA.getClass()); // true
    }
}

class CloneB extends CloneA {
    public CloneB clone() throws CloneNotSupportedException {
        Object o2 = super.clone();       // still reaches Object.clone through the chain
        return (CloneB) o2;
    }

    public static void main(String[] args) throws CloneNotSupportedException {
        CloneB b = new CloneB();
        CloneB clonedB = b.clone();
        System.out.println(b.hashCode());       // e.g. 366712145
        System.out.println(clonedB.hashCode()); // e.g. 1829164700 — different number
        System.out.println(b == clonedB);       // false
        System.out.println(b.hashCode() != clonedB.hashCode()); // true — H1 != H2
    }
}

Real-world: cloning is the basis of the Prototype pattern — a graphics editor clones a Shape prototype to create new shapes with preset style, or a web request handler clones a template Employee record before applying a tentative raise, so the original stays untouched if validation fails.

24.4 Shallow Copy versus Deep Copy

24.4.1 Shallow Copy — What Object.clone Gives You by Default

The Object.clone() path performs a shallow copy. It copies the top-level object and copies each field value as it is. For a primitive field like int salary, the value 35000 is duplicated by value, so the two employee boxes hold independent 35000s. For a reference field like String name or Date hireDate, the reference itself — the arrow — is duplicated, not the object it points to.

class Employee implements Cloneable {
    String name;    // reference to String box
    int salary;     // primitive
    Date hireDate;  // reference to mutable Date box
    public Employee clone() throws CloneNotSupportedException {
        return (Employee) super.clone(); // shallow only
    }
}

Employee E = new Employee();
E.name = "Smith";          // String at 1064
E.salary = 35000;
E.hireDate = new Date();   // Date at 2044, e.g. 15 Jan 2020
Employee cloned = E.clone();

System.out.println(cloned.hireDate); // e.g. 15 Jan 2020
E.hireDate.setMonth(5);              // mutate through E
System.out.println(cloned.hireDate); // now June — changed via E's arrow
System.out.println(E.name == cloned.name);       // true — shared String
System.out.println(E.hireDate == cloned.hireDate); // true — shared Date

Visual intuition: picture a photocopier that copies a folder cover and staples copies of the sticky notes that say "see document at 1064." The documents themselves are not photocopied. For a String document laminated in plastic, sharing the original is fine; for a pencil-written Date note, two people sharing one note will overwrite each other's edits.

24.4.2 Deep Copy — Copying the Referenced Objects as Well

A deep copy is a fully independent copy that duplicates the entire reachable object graph, including the objects that reference fields point to. In the textbook terms, it is a "sufficiently deep" copy — deep enough for correctness.

class Employee implements Cloneable {
    String name;
    int salary;
    Date hireDate;

    public Employee clone() throws CloneNotSupportedException {
        Employee cloned = (Employee) super.clone(); // shallow step: 1000 -> 2000
        cloned.hireDate = (Date) hireDate.clone();  // explicit deep step for mutable field
        return cloned;
    }
}

Employee E = new Employee("Smith", 35000, new Date()); // name@1064, hireDate@2044
Employee cloned = E.clone();

System.out.println(E.hireDate == cloned.hireDate); // false — now two Date boxes (3024 vs 2044)
System.out.println(E.name == cloned.name);          // true — still one String (safe)
E.hireDate.setYear(2025);
System.out.println(cloned.hireDate.getYear()); // still 2020 — no leak

Exam note: Expect to label a given clone as shallow or deep, to state what happens to hireDate after E.hireDate.setMonth(...) in each case, and to write the deep-copy line cloned.hireDate = (Date) hireDate.clone(); with the String versus Date mutability justification.

24.5 Garbage Collection and Object Lifecycle

24.5.1 What Garbage Collection Does

Garbage collection is the automatic reclamation of memory occupied by objects that are no longer reachable. When an object has no live reference pointing to it — no arrow from any variable, array slot, or field still reaches it — it is unreferenced and becomes eligible for collection. The runtime can then free the memory so it can be reused, without the programmer calling a free operation.

Visual intuition: a directed graph with nodes for objects and edges for references. Roots are stack variables and static fields at the top; reachable nodes are those with any path from a root. White nodes with zero incoming paths are eligible. The collector's job is to erase white nodes. The takeaway is that reachability, not reference count alone, decides eligibility.

24.5.2 Three Ways an Object Becomes Unreferenced

The lecture listed three concrete patterns that make an object eligible, each framed as "available for garbage collection," not "destroyed immediately."

ABC a = new ABC();  // a -> object at, say, 1000
a = null;           // arrow severed, box at 1000 now has no incoming edge

Test t1 = new Test(); // t1 -> box A (alive)
Test t2 = new Test(); // t2 -> box B (alive)
t2 = t1;              // t2 now -> A; B loses its sole arrow

new Test(); // allocate box C, return its address, but store it nowhere

Sense-check: printing t2 after t2 = t1 shows the value from t1, not the old t2 value, confirming the old box was abandoned.

24.5.3 Finalize and Explicit GC Signaling

Two additional mechanisms were covered that sit beside eligibility:

class Resource implements AutoCloseable {
    protected void finalize() throws Throwable {
        try { cleanupNativeHandle(); }
        finally { super.finalize(); }
    }
    public void close() { cleanupNativeHandle(); }
}

ABC a = new ABC();
a = null;
System.gc();      // hint: "an eligible object exists"
Runtime.getRuntime().gc(); // same hint via singleton

Real-world: long-running services avoid slow memory growth by nulling or removing cached objects when entries expire, and by avoiding patterns that create many short-lived anonymous objects inside tight loops. For leak hunting, engineering teams snapshot Runtime.freeMemory() and totalMemory() before and after a workload, request System.gc(), and watch whether free space returns to baseline.

24.6 Java Runtime Classes and Memory Introspection

24.6.1 The Runtime Environment and Why a Runtime Class Exists

Java is described as platform independent because it separates the language from the machine through the Java Virtual Machine and the Java Runtime Environment. The source compiles to bytecode, the bytecode runs on the JVM, and the JVM talks to the operating system. To let a portable program ask environment questions — how much memory is free, how much is total, when to run the collector, how to launch a process — the standard library provides java.lang.Runtime.

Runtime r = Runtime.getRuntime(); // the only Runtime object
long free = r.freeMemory();
r.gc();           // hint at GC via the same singleton
Process p = r.exec("notepad"); // launch external process (when permitted)

Visual intuition: picture a computer chassis. Inside, a large rectangle is the OS memory. A shaded sub-rectangle inside it is the JVM heap. Runtime is the small status LCD on the heap's frame that reports "total allocated" and "free inside." The LCD does not show outside-the-heap RAM; it shows what the JVM currently owns.

24.6.2 Memory Queries and Worked Calculations

Three methods formed a small example chain that the session tied directly to garbage-collection intuition:

• public long freeMemory() — amount of free memory in the JVM heap, in bytes (long because heaps can exceed Integer.MAX_VALUE).
• public long totalMemory() — total memory allocated to the JVM by the OS so far, in bytes.
• Derived used memory — computed as used = total - free. Also derived max approximations via freeMemory + used.

class ABC {
    public static void main(String[] args) {
        Runtime r = Runtime.getRuntime();
        long free = r.freeMemory();  // e.g. 266421656
        long total = r.totalMemory(); // e.g. total bytes reported next
        System.out.println("Free: " + free);
        System.out.println("Total: " + total);
        System.out.println("Used bytes: " + (total - free));
        System.out.println("Used MB: " + (total - free) / (1024 * 1024));
    }
}

long free = 266421656L;                // bytes free
long total = 267470232L; // example total that makes used ≈ 1 MB (session reported 1 MB used)
long usedBytes = total - free;        // 1048576 bytes
long usedKB = usedBytes / 1024;       // 1024 KB
long usedMB = usedKB / 1024;          // 1 MB

Other Runtime capabilities mentioned in passing include executing a process with exec(String) and invoking the garbage collector with gc(), both accessed through the same singleton. The session treated these as the same gateway idea: the JVM environment is a single place you ask about resources.

Real-world: production services log Runtime.getRuntime().freeMemory() and totalMemory() periodically to track heap pressure, to decide cache eviction, and to alert when free falls below a threshold. Operators size heap with -Xms/-Xmx and watch these counters after deployments to verify GC tuning.

24.7 Java Type System

24.7.1 What a Type Is

A type is a set of values together with the set of operations that can be applied to those values. For a class type Account, the values are the possible states of its data members (every distinct combination of field values that could exist), and the operations are the methods you can call on an account — deposit, getBalance, toString. The same pairing applies to primitives, where the values of int are the $2^{32}$ bit patterns and the operations include +, -, *, /, ==.

An analogy: a type is like a board game box. The values are the board positions reachable in that game; the operations are the moves the rulebook allows. A chess box allows knight moves; a checkers box does not. Swapping boxes changes both positions and legal moves.

24.7.2 The Six Kinds of Type in Java

The session enumerated the complete non-generic type inventory from the language spec:

• Primitive types — int, short, long, byte, char, float, double, boolean. These are the built-in value types you already know. No heap object, no Object methods, no null.
• Class types — every class is a type. If you write class ABC or class XYZ, the name ABC and the name XYZ each denote a type whose values are the possible objects of that class and whose operations are its methods.
• Interface types — an interface is also a type, even though you cannot instantiate it directly with new. Its values are references to objects of classes that implement it.
• Array types — an array such as int[] or String[] is its own type with indexing arr[i], length field, and inherited Object methods. Component type matters for subtyping.
• Null type — the type of the null value. The spec defines it as the type with the single value null, so every value, including null, belongs to exactly one type. null is a subtype of every non-primitive type, which is why you can write String s = null; but not int x = null;.
• Void is not a type — void is a return-position marker meaning "no value is returned," not a set of values with operations. Do not list void as a sixth type alongside primitives.

int n = 13;                   // primitive type value
Rectangle r = new Rectangle(); // class type value
Shape s = r;                  // interface type variable holding Rectangle
String[] words = {"hi"};      // array type
Object o = null;              // null type value stored in Object variable
void m() { return; }          // void marks no value, not a type of value

Visual intuition: draw five columns labeled Primitive, Class, Interface, Array, Null. Under each, place example tokens: 42, new ABC(), Shape variable, int[], null. Cross out void placed outside the table with a "not a type" note. The takeaway is that every expression you write lands in one column, and null has its own column.

24.7.3 Supertypes and Subtypes

When B extends A, or when B implements an interface A, the inheritance relation becomes a type relation with rules for substitution:

• A is a supertype of B — it is the parent in the hierarchy, with members that the child can use when they are public or protected.
• B is a subtype of A — it inherits members and can directly call methods of the supertype.

The lecture phrased this as "A is supertype of B, B is subtype of A" and noted it is the same hierarchy you already know from inheritance, now read as a statement about types rather than just about classes.

Illustration with the textbook figure: Object at the top, Component -> Container -> JComponent -> AbstractButton -> JButton vertically. LayoutManager interface with LayoutManager2 subtype, and FlowLayout implementing LayoutManager. The point is that subtype edges follow both extends and implements.

24.7.4 What Can Appear on the Right-Hand Side of an Instantiation

Given a type X and an object x1, what expression can you legally place on the right of X x1 = ...? The answer depends on what X is, and the session returned to this table several times to link declared type versus actual runtime type:

• If X is an interface — you cannot write new X() because interfaces cannot be instantiated directly (they have no constructor body to allocate). The right-hand side must be an instance of any class that implements X. Writing X x1 = new ClassThatImplementsX() is the correct shape.
• If X is an abstract class — you again cannot write new X() directly, because abstract classes leave methods unimplemented. The right-hand side must be an instance of any concrete (non-abstract) subclass that extends X. Only the concrete child can be created.
• If X is a concrete class — the right-hand side can be new X() itself, or new SubclassOfX() for any subclass of X.

interface Shape { void draw(); }
abstract class AbstractShape implements Shape { }
class Rectangle extends AbstractShape { void draw() {} }
class Circle extends AbstractShape { void draw() {} }

Shape s1 = new Rectangle();        // legal — Rectangle implements Shape
Shape s2 = new Circle();           // legal — Circle implements Shape
// Shape s3 = new Shape();         // illegal — interface cannot be new'd
// AbstractShape a1 = new AbstractShape(); // illegal — abstract cannot be new'd
AbstractShape a2 = new Rectangle(); // legal — concrete subtype
Rectangle r1 = new Rectangle();     // legal — same class
Rectangle r2 = new Rectangle();     // Rectangle r = new Circle(); // illegal — sibling, not subtype
Shape s4 = new AbstractShape() { void draw() {} }; // legal via anonymous concrete subclass

Visual intuition: a decision tree with root "What is X?" branching to Interface (must pick implementing class), Abstract (must pick concrete child), Concrete (may pick self or child). Each leaf shows new with a class name that satisfies the edge label. The takeaway is that new always names a concrete class; the left-hand type decides which concretes are allowed.

Real-world: subtype rules explain why a method void paint(Component c) can accept a JButton, why a List<Component> cannot hold int without boxing, and why frameworks declare handler parameters as Object or interface types to accept many implementations while still needing the inquiry tools of the next section to recover the concrete type when behavior must branch.

24.8 Type Inquiry — Finding the Actual Type of an Object or Class

24.8.1 instanceof — Is This Value a Subtype of That Type?

The instanceof operator tests whether the type of an object is a subtype of a given type. It answers "does this object belong to this family?" rather than "what is its exact class?" The result is boolean, and null instanceof T is false (no exception).

Given a class Shape and an object e:

e instanceof Shape

This expression returns true if e is of type Shape itself or of any subclass of Shape (including indirect subclasses), and false otherwise. Because the test is inclusive of subclasses, a true result does not tell you the concrete class — a rectangle object and a circle object would both return true for instanceof Shape.

class Shape { void draw() {} }
class Rectangle extends Shape { }
class Box { } // does not extend Shape

Object x = new Rectangle(); // Rectangle extends Shape
if (x instanceof Shape) {
    Shape s = (Shape) x; // safe because the test already passed
    // s.draw() now valid
}
System.out.println(new Rectangle() instanceof Shape); // true — Rectangle isSubtype Shape
System.out.println(new Box() instanceof Shape);       // false — Box unrelated

// For the lecture's direct contrast:
Object y = new Box();
if (y instanceof Shape) {
    Shape s2 = (Shape) y; // not reached, because y instanceof Shape is false
} else {
    System.out.println("y is Box, not a Shape — cast would fail, so we skip");
}

Visual intuition: draw a Venn-like subtype tree. Largest oval is Object, inner oval is Shape, inner-most oval is Rectangle; a separate disconnected oval is Box. Drop a dot for x inside Rectangle (hence also inside Shape and Object) and for y inside Box. instanceof Shape asks "is the dot inside the Shape oval?" The takeaway is inside = true, outside = false, and inside innermost already means inside all ancestors.

24.8.2 getClass and getName — The Exact Runtime Type

When you need the precise class, not just family membership, use getClass():

Class c = e.getClass(); // e is any non-null object reference

The left-hand side type is Class, written as Class<?> or Class in the lecture as a type descriptor. A Class object carries information about the type — its name, its superclass, array status, component type, and other reflective details. From it you can ask for the name:

String name = e.getClass().getName(); // e.g. "Shape" or "Rectangle"
System.out.println(e.getClass().getName());

If e holds a Rectangle, getName() returns "Rectangle" (in package java.awt it returns "java.awt.Rectangle"), not just "Shape". This is the difference from instanceof: getClass gives the concrete class that the object actually belongs to right now, while instanceof gives a family check.

Shape e = new Rectangle();
System.out.println(e.getClass().getName()); // prints "Rectangle" — exact type
System.out.println(e instanceof Shape);     // true — family
System.out.println(e instanceof Rectangle); // true — family includes self
System.out.println(e.getClass() == Rectangle.class); // true — exact
System.out.println(e.getClass() == Shape.class);     // false — exact is Rectangle, not Shape

// Null nuance:
Object n = null;
// n.getClass() would throw NullPointerException — guard with null check or instanceof
System.out.println(n instanceof Shape); // false, safe on null

24.8.3 The .class Suffix and Class-Object Comparison

A third inquiry path uses the .class suffix. Writing .class after a type name yields the Class object that describes that type without needing an instance:

Class c1 = Rectangle.class; // descriptor for the Rectangle type
Class c2 = e.getClass();     // descriptor for the actual object e
// Also: int.class describes the primitive int type; String[].class describes array type
Class c3 = Class.forName("java.awt.Rectangle"); // same descriptor via name lookup

For every type loaded into the virtual machine there is exactly one Class object. That uniqueness makes reference comparison meaningful:

if (e.getClass() == Rectangle.class) {
    // e's exact type is Rectangle
}
if (e.getClass() == Shape.class) {
    // would mean e was exactly a Shape instantiation, not a subtype
}

The == here compares descriptor references, not content. Because the VM holds a single canonical Class object per type, two descriptors for the same type are == to each other, and descriptors for different types are not. This lets you test "is the exact type Rectangle?" in addition to the broader "is it a kind of Shape?" test that instanceof provides.

Shape a = new Rectangle();
Shape b = new Circle(); // assume Circle extends Shape
System.out.println(a.getClass() == Rectangle.class); // true — exact match
System.out.println(b.getClass() == Rectangle.class); // false — Circle descriptor != Rectangle descriptor
System.out.println(a instanceof Rectangle);            // true — family again
System.out.println(a.getClass() == Shape.class);      // false — exact is Rectangle

// Choosing between the two tools:
void handle(Shape s) {
    if (s instanceof Shape) { /* any shape accepted */ }
    if (s.getClass() == Rectangle.class) { /* only Rectangle, not Circle nor Square extends Rectangle */ }
}

Real-world: application code guards casts in heterogeneous collections with if (x instanceof Shape) { Shape s = (Shape) x; } to avoid ClassCastException. Frameworks and JSON serializers use obj.getClass() == Rectangle.class or getClass().getName() for exact-type routing, logging, and audit. Debuggers print e.getClass().getName() to show which concrete class is actually live when a Shape variable surprises you.

24.9 Enum Types — A Finite Set of Values

24.9.1 Why Enum Is a Special Type

An enum is a type that holds a finite, fixed set of named values and no others. If you define an enum Size with values SMALL, MEDIUM, LARGE, then every value of type Size is one of those three. You cannot create a fourth size value at runtime; size++ that would produce 4 on an int-backed fake enum is impossible with a real enum because the type itself is the catalogue. That boundedness is the entire point: it restricts a program to a known catalogue and lets the compiler check type errors.

24.9.2 Syntax and What the Enum Keyword Really Creates

Syntax:

enum Size {
    SMALL, MEDIUM, LARGE
}

What this declaration creates under the surface is a class with a private constructor and a fixed number of instances. Conceptually:

// expansion of enum Size { SMALL, MEDIUM, LARGE } — not what you write, but what it means
class Size {
    private Size() { } // private — objects cannot be created outside the class
    public static final Size SMALL  = new Size();
    public static final Size MEDIUM = new Size();
    public static final Size LARGE  = new Size();
}

Because the constructor is private, outside code cannot call new Size(). The only instances that ever exist are the public static final ones named in the enum body. They are accessed statically as Size.SMALL, Size.MEDIUM, Size.LARGE. At class-load time, the VM creates exactly those instances, in the order written, and no more.

The session also used a Season example with four constants:

enum Season {
    WINTER, SPRING, SUMMER, FALL
}
// conceptual:
public static final Season WINTER = new Season();
public static final Season SPRING = new Season();
// ...

Every element (WINTER etc.) is a value of the enum type, and the enum type itself functions as a class whose instances are exactly those listed values.

Placement is flexible: an enum can be declared outside a class at the top level, or inside a class as a member. Both styles appeared:

// outside — top level enum Season
enum Season { WINTER, SPRING, SUMMER, FALL }
class ABC { void show(Season s) { System.out.println(s); } }

// inside — member enum Season
class ABC {
    enum Season { WINTER, SPRING, SUMMER, FALL }
    void show(Season s) { System.out.println(s); }
}

The difference is namespace and access (ABC.Season when nested), not capability.

24.9.3 Working with Enum Values — values, valueOf and ordinal

class ABC {
    enum Season { WINTER, SPRING, SUMMER, FALL }

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

Season s = Season.WINTER;
System.out.println(s); // WINTER
s = Season.SUMMER;
System.out.println(s); // SUMMER
// s can also be null: Season t = null; // allowed, but null is not a Season value

System.out.println(Season.WINTER.ordinal()); // 0
System.out.println(Season.SPRING.ordinal()); // 1
System.out.println(Season.SUMMER.ordinal()); // 2
System.out.println(Season.FALL.ordinal());   // 3

// valueOf identity case (no extra field):
System.out.println(Season.valueOf("WINTER")); // WINTER — the value of WINTER is WINTER
System.out.println(Season.valueOf("WINTER") == Season.WINTER); // true — same singleton

for (Season s : Season.values()) {
    System.out.println(s + " ordinal " + s.ordinal());
}
// WINTER ordinal 0
// SPRING ordinal 1
// SUMMER ordinal 2
// FALL ordinal 3

Visual intuition: place four labeled tokens in order on a rail: position 0 WINTER, 1 SPRING, 2 SUMMER, 3 FALL. ordinal() reads the position number; valueOf("WINTER") picks the token at position 0; values() returns the whole rail as an array. The takeaway is name lives on the token, index is separate.

24.9.4 Giving Enum Constants Their Own Data — Initial Values and a Private Constructor

You can attach data to each constant by giving it a constructor argument. This is how the lecture modelled WINTER(5) etc. — each season carries a number that travels with the constant:

enum Season {
    WINTER(5), SPRING(10), SUMMER(15), FALL(20);

    private int value; // the attached data for this constant

    private Season(int value) {
        this.value = value; // this.value = value — field gets parameter
    }
    int getValue() { return value; }
}

public static void main(String[] args) {
    for (Season s : Season.values()) {
        System.out.println(s + " " + s.value);
        // prints: WINTER 5, SPRING 10, SUMMER 15, FALL 20
    }
}

24.9.5 Feature Summary for Enum

The session closed the enum topic with a short checklist that again ties back to the expansion above:

• Every enum implicitly extends java.lang.Enum (so it cannot extend another class and cannot be subclassed).
• toString() returns the enum constant's name ("WINTER" for WINTER).
• values() returns all constants present in the enum — use with for-each to traverse the catalogue.
• ordinal() returns the declaration index (WINTER 0, FALL 3).
• compareTo and compareTo order follow ordinal; equals is == for enums.
• An enum can declare a constructor; it must be private or package-private in effect, and it is executed separately for each constant at class-loading time, in the order written.
• Enum objects cannot be created explicitly with new, and the enum constructor cannot be invoked directly from outside — that is why the set remains bounded.
• An enum can contain concrete methods but not abstract methods in the lecture's presented form (a fully detailed enum with per-constant class bodies can have abstract methods, but that variant was not in this session).
• Bonus: because Enum implements Comparable, you can store enums in TreeSet/TreeMap with natural ordinal order, and because String.valueOf(s) delegates to toString(), printing is the name.

Real-world: enums are used wherever a catalogue must be closed — Size { SMALL, MEDIUM, LARGE } for a product line, Season { WINTER, SPRING, SUMMER, FALL } for calendar logic, OrderStatus or DayOfWeek in services — so callers cannot pass an arbitrary string like "winter" with a typo, and the compiler, not runtime validation, guarantees only valid values flow through the system.

24.10 Bounded Types — Restricting a Generic Parameter

24.10.1 Recap — Unbounded Generics

To make the restriction clear, the session first reviewed the plain generic class. This recap anchors the bounded form that follows:

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

Identity<Long> number = new Identity<>(123L);
System.out.println(number.getObj()); // T is Long, getObj returns Long, prints 123
System.out.println(number.getObj().getClass().getName()); // java.lang.Long

Identity<String> name = new Identity<>("unk");
System.out.println(name.getObj());   // T is String, getObj returns String, prints unk
System.out.println(name.getObj().getClass().getName()); // java.lang.String

class Test {
    public static void main(String[] args) {
        Identity<Long> x = new Identity<>(123L);
        Identity<String> y = new Identity<>("hello");
        System.out.println(x.getObj()); // 123 — T was Long
        System.out.println(y.getObj()); // hello — T was String
        // Identity<int> z = new Identity<>(5); // illegal — primitives need wrapper Integer
    }
}

Visual intuition: a rubber stamp cut as T obj. Press it once with Long ink — the imprint reads Long obj; ink it with String — the imprint reads String obj. The stamp shape does not change, but the ink color (type argument) does. The takeaway is one definition, many inkings.

24.10.2 What Bounding Means

A bounded type restricts which types may be used as arguments for a parameterized type. Instead of allowing any T, you say "T must be A or a subtype of A." That is, T must stand in an inheritance relationship with a stated upper bound. The compiler then knows every allowed T has the members of A, so calling A members through T is safe.

The syntax uses extends — the same word that declares subclassing — even when the bound is an interface (there, extends still means "subtype of"):

class Identity<T extends A> { ... }
// class Bound<T extends A> { ... } // same pattern named Bound in the variant example

Comparison table — unbounded vs bounded:

When to pick which: use unbounded when the container truly works for any type; use bounded when the body needs operations promised by the bound.

24.10.3 Worked Example — A, B and C

class A {
    void displayClass() { System.out.println("Inside super class A"); }
}
class B extends A {
    void displayClass() { System.out.println("Inside class B"); }
}
class C extends A {
    void displayClass() { System.out.println("Inside class C"); }
}

class Bound<T extends A> {
    private T objRef;
    Bound(T obj) { this.objRef = obj; }
    void doRunTest() {
        objRef.displayClass(); // valid because upper bound A guarantees displayClass exists
    }
}

class BoundedClass {
    public static void main(String[] args) {
        Bound<C> bCc = new Bound<>(new C());
        bCc.doRunTest(); // prints "Inside class C"

        Bound<B> bCb = new Bound<>(new B());
        bCb.doRunTest(); // prints "Inside class B"

        Bound<A> bCa = new Bound<>(new A());
        bCa.doRunTest(); // prints "Inside super class A"
    }
}

Real-world: bounded generics keep container Stats<T extends Number> safe for average() that calls doubleValue(), and let a cache Cache<T extends Persistent> guarantee save() exists. In the strategy pattern arenas of T1 and T4, similar constraints appear as Repository<T extends Entity> — the bound ensures persistence operations exist without tying the repository to one concrete Employee or Order class.

24.11 Generic Methods and Generic Interfaces

24.11.1 Generic Methods — Parameterized at the Method Level

A generic method carries its own type parameter, independent of whether its enclosing class is generic. That lets a single operation be type-flexible while the rest of the class stays non-generic. The lecture contrasts this with a generic class where every member shares the same T.

<T> T getObject(T obj) { return obj; }

class Identity<T> {
    void printObject(T obj) {
        System.out.println(obj.getClass().getName());
        System.out.println(obj);
    }
}

class Identity<T> {
    void printObject(T obj) {
        System.out.println(obj.getClass().getName());
        System.out.println(obj);
    }
    <U> U getObject(U obj) { return obj; } // generic method — declares U
}
class Demo {
    public static void main(String[] args) {
        Identity<?> helper = new Identity<>();
        helper.printObject(123);      // T inferred as Integer — prints java.lang.Integer and 123
        helper.printObject("hello");  // T inferred as String  — prints java.lang.String  and hello

        String s = helper.<String>getObject("hi"); // explicit type arg — returns String
        Long n = helper.<Long>getObject(123L);     // returns Long
    }
}

Visual intuition: a generic class is a tinted warehouse where every aisle shares the same color; a generic method is one aisle that can change color at will while the rest of the warehouse stays neutral. The takeaway is class-level T fixes the whole class; method-level <T> fixes just that method call.

24.11.2 Generic Interfaces — Declaring and Implementing with Parameters

An interface can also be parameterized. Instead of a single concrete contract like interface Converter { Integer convert(String); } tied to two types, a generic interface describes a shape that implementors fill with chosen types.

interface DemoInterface<T1, T2> {
    T2 doSomeOperation(T1 t);
    T1 doReverseOperation(T2 t);
}

interface DemoInterface<T1, T2> {
    T2 doSomeOperation(T1 t);
    T1 doReverseOperation(T2 t);
}

class DemoClass implements DemoInterface<String, Integer> {
    public Integer doSomeOperation(String s) {
        return s.length(); // consumes String, produces Integer
    }
    public String doReverseOperation(Integer n) {
        return String.valueOf(n); // consumes Integer, produces String
    }
}

// Use site:
DemoInterface<String, Integer> d = new DemoClass();
System.out.println(d.doSomeOperation("hello"));   // 5 — String -> Integer
System.out.println(d.doReverseOperation(5));      // "5" — Integer -> String

class ABC<T1, T2> implements DemoInterface<T1, T2> { // pass-through generics
    public T2 doSomeOperation(T1 t) { /* generic body */ return null; }
    public T1 doReverseOperation(T2 t) { return null; }
}

The session closed the entire module by connecting this back to bounded types — a generic interface can also be bounded, for example interface Converter<T extends Number>, though the worked code kept the bound on the class side — and by advising hands-on practice: copy each small program, run it, swap Long for String or C for B, and watch how the compiler accepts or rejects the change. Swaps that violate bounds produce compile-time red, not runtime surprises.

Real-world: generic interfaces are common in library design — Converter<T1, T2> with T2 convert(T1) and T1 reverse(T2), Repository<T> or Comparator<T>, and Guava-like Function<T1,T2> — where the same contract must work for String/Integer, Long/String, or other pairs without duplicating the interface text. A single DemoInterface<String, Integer> can drive a form mapper, while DemoInterface<Long, String> with the same source text drives an ID stringifier.

Exam Guidance Summary

The session is the final content-covering contact session; the next two sessions are review and revision of all prior topics. The items below pull together every explicit exam hint given for Lecture 24, organized by concept so you can drill directly.

Practical preparation advised in the session: copy each small program (Account, CloneA/CloneB, Employee shallow/deep, Bound, Identity, DemoClass), run it locally, swap type arguments (Long versus String, B versus C, String/Integer mapping) and observe compiler acceptance versus rejection and runtime hashCode/getName outputs. That running practice also prepares for viva-style "what if I change this line?" questions.

Key Industry Applications

• Universal Object root — Any framework can accept Object and call toString/equals/hashCode for logging, collections, and debugging without knowing the concrete class. For example, a logging aspect log(Object x) prints x.toString() for any domain entity because Object guarantees it.

• Content equality with equals versus identity with == — The basis of correct behavior in hash-based collections like HashMap and HashSet, where hashCode and equals must agree. A correctly overridden Employee.equals and hashCode lets a HashSet<Employee> detect duplicate hires; identity == would treat equal-content employees as distinct.

• Cloning for safe snapshots — Duplicating a business entity such as an Employee or Account before a tentative update, so the original remains untouched if the change is rolled back. Implemented with super.clone() plus Cloneable, as in CloneA/CloneB and Account, this is the coded form of the Prototype pattern used in editors and transaction staging.

• Shallow versus deep copy discipline — Choosing to share immutable String fields at 1064 while explicitly deep-copying mutable Date or collection fields at 2044/3024. That decision appears in data-transfer objects, message cloning in queues, and prototype copies where shared mutable state would leak edits between copies.

• Garbage collection awareness — Writing allocation patterns that let the JVM reclaim quickly (nulling caches, avoiding long-lived anonymous objects, understanding eligibility via nulling/reassigning/anonymous new Test()) in long-running services so heap does not grow without bound and System.gc() remains an advisory hint rather than a fix.

• Runtime memory introspection — Monitoring Runtime.getRuntime().freeMemory() and totalMemory() to size caches, tune heap with -Xmx, or log memory pressure in production diagnostics. Computing used = total - free and usedMB = used / (1024*1024) (the 266421656 to 1 MB drill) drives capacity alerts and cache eviction logic.

• Type system and inquiry — Using instanceof guards before casts in heterogeneous collections (if (x instanceof Shape) { Shape s = (Shape) x; }) to avoid ClassCastException, and using getClass()/getName() or Rectangle.class == e.getClass() for exact-type routing in serializers, ORMs, and message dispatchers where Box versus Rectangle must branch differently.

• Enums as closed catalogues — Modeling fixed domains like Size { SMALL, MEDIUM, LARGE } or Season { WINTER, SPRING, SUMMER, FALL } or OrderStatus so callers cannot pass arbitrary strings. Attached data such as WINTER(5) turns the enum into a type-safe lookup table where invalid values are caught at compile time and iteration via values() drives batch handling.

• Bounded generics — Constraining a generic container or operation to T extends Number or T extends A so type-safe operations like displayClass() or average() with doubleValue() are guaranteed to exist. Bound<T extends A> is the teaching example; production uses include Cache<T extends Entity> and Stats<T extends Number>.

• Generic interfaces — Defining reusable contracts such as DemoInterface<T1, T2> or Converter<T1, T2> or Repository<T> that work across String/Integer, Long/String, or other pairs without duplicating interface text. DemoClass implements DemoInterface<String, Integer> maps T1->String, T2->Integer once, giving Integer doSomeOperation(String) and String doReverseOperation(Integer) with full compile-time safety.

Together these patterns appear in frameworks from Spring (generic repositories) to Android (type inquiry and enums for state machines) and in every service that batches Employee snapshots, monitors heap, or designs a closed catalogue type.