Java Fundamentals & the JVM

== on reference types checks reference identity — are both variables pointing at the exact same object on the heap? .equals() checks logical equality, whatever the class defines it to mean (by default, Object.equals also just does identity comparison, unless overridden).

String a = new String("hi");
String b = new String("hi");

a == b;         // false — different objects
a.equals(b);    // true  — same content

String c = "hi";
String d = "hi";
c == d;         // true — both point at the same interned literal in the string pool

For classes like String, wrapper types, and records, .equals() is overridden to compare contents. For custom classes, you must override equals() (and hashCode(), per the equals/hashCode contract) to get meaningful value comparison — otherwise it falls back to identity comparison from Object.

On primitives, == simply compares values, since there's no object identity involved (5 == 5 is always true).

Rule of thumb: use == for primitives and for intentional reference/identity checks (e.g., singleton checks); use .equals() whenever comparing the content of objects.

The contract, defined on Object, has three parts:

1. Consistency: repeated calls to hashCode() return the same value as long as no field used in equals() changes.
2. Equal implies equal hash: if a.equals(b) is true, then a.hashCode() == b.hashCode() must be true.
3. Unequal doesn't require different hash: two unequal objects may share a hash code (a collision) — that's allowed and expected, hash-based structures handle it.

Why it matters: HashMap/HashSet locate a bucket using hashCode(), then use equals() to distinguish entries within that bucket. If you override equals() but not hashCode(), two "equal" objects can land in different buckets — a HashSet might contain what look like duplicates, and map.get(key) can fail to find an entry you just put in.

public class Point {
    private final int x, y;
    // ...
    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Point p)) return false;
        return x == p.x && y == p.y;
    }
    @Override
    public int hashCode() {
        return Objects.hash(x, y); // must use the same fields as equals()
    }
}

Modern Java: record types generate a correct equals()/hashCode()/toString() automatically based on their components, which is one of their main appeals for simple data carriers.

String is immutable — once created, its character content can never change; every "modifying" operation (concat, substring, replace, ...) returns a new String.

Because strings can't be mutated, the JVM can safely let many references share the same underlying String object. The string pool (part of the heap since Java 7) is a table of unique string instances. String literals are automatically interned:

String a = "hello";
String b = "hello";
a == b;                      // true — both point at the same pooled instance

String c = new String("hello"); // forces a new, non-pooled object
a == c;                      // false
c.intern() == a;             // true — intern() looks up/adds to the pool

Benefits: memory savings (one copy of a repeated literal) and fast reference comparisons for pooled strings.

Why immutability enables this: if String were mutable, sharing instances would be dangerous — modifying one reference would silently corrupt every other reference to the "same" string. Immutability is also why String is safe as a HashMap key (its hash code is cached after first computation) and safe to share across threads without synchronization.

Despite the similar spelling, these three are unrelated:

• final (modifier): applied to a variable (can't be reassigned after initialization), a method (can't be overridden), or a class (can't be subclassed).

final int MAX = 100;      // constant reference
class Utils { final void helper() {} } // can't override
final class ImmutablePoint {}          // can't extend

• finally (block): part of try/catch/finally, guaranteed to run whether or not an exception occurred (barring System.exit() or JVM crash) — used for cleanup like closing resources.

try {
    risky();
} finally {
    cleanup(); // always runs
}

• finalize() (method, deprecated since Java 9, slated for removal): an Object method the GC might call before reclaiming an unreachable object, meant for last-resort resource cleanup. It's unreliable (no guarantee it runs promptly, or at all), hurts GC performance, and can resurrect objects. Modern code uses try-with-resources (AutoCloseable) or java.lang.ref.Cleaner instead.

static marks a member as belonging to the class, not to any particular instance:

• Static fields: one copy shared by all instances (e.g., a counter of how many objects were created).

class Counter {
    static int instances = 0;
    Counter() { instances++; }
}

• Static methods: callable via the class name, without an instance (Math.max(a, b)); they cannot reference this or instance fields directly, since there's no instance involved.
• Static initializer blocks: static { ... } runs once, when the class is first loaded, useful for one-time setup of static state.
• Static nested classes: a nested class marked static doesn't get an implicit reference to an enclosing instance (unlike a regular inner class), so it can be instantiated independently: new Outer.StaticNested().
• Static imports: import static java.lang.Math.*; lets you call max(a, b) instead of Math.max(a, b).

Common use cases: utility/helper methods (Collections.sort), constants (static final), factory methods, and singleton implementations.

Java has two kinds of initializer blocks, run at different times:

• Static initializer block (static { ... }): runs exactly once, when the class is first loaded/initialized by the JVM — before any instance is created and before main() even, if that class contains it.
• Instance initializer block ({ ... }, no static): runs every time a new instance is constructed, right after the superclass constructor completes and before the current class's constructor body executes.

Full order when creating an object of a subclass for the first time:

1. Superclass static blocks/fields (in source order) — once, on first load.
2. Subclass static blocks/fields (in source order) — once, on first load.
3. For each new call: superclass constructor runs (which itself runs superclass instance blocks, then its constructor body) → subclass instance blocks/field initializers (in source order) → subclass constructor body.

class Base {
    static { System.out.println("Base static"); }
    { System.out.println("Base instance"); }
    Base() { System.out.println("Base ctor"); }
}
class Derived extends Base {
    static { System.out.println("Derived static"); }
    { System.out.println("Derived instance"); }
    Derived() { System.out.println("Derived ctor"); }
}
new Derived();
// Base static, Derived static, Base instance, Base ctor, Derived instance, Derived ctor

Static blocks are useful for one-time setup (loading config, registering drivers); instance blocks are less common than field initializers but useful for logic that field initializers can't express (e.g., a switch during setup) shared by every constructor.

Class loading is how the JVM turns a .class file into a Class object usable at runtime. It happens lazily, on first active use of a class, and goes through three phases: loading (reading bytecode into memory), linking (verification, preparation of static fields, resolution of symbolic references), and initialization (running static initializers).

Class loaders form a hierarchy, and (by default) use parent delegation: before a loader tries to load a class itself, it asks its parent to try first. This prevents core classes from being shadowed by application code and lets each class have one authoritative loader.

• Bootstrap class loader: written in native code (part of the JVM itself), loads the core Java SE classes (java.lang.*, java.util.*, ...) from the runtime's module image. Has no parent (represented as null in code).
• Platform class loader (formerly "Extension" loader pre-Java 9): loads classes from platform/extension modules that aren't core but ship with the JDK.
• Application (System) class loader: loads classes from your application's classpath or module path — this is the loader that finds your own compiled classes and third-party JARs, and is what ClassLoader.getSystemClassLoader() returns.

Frameworks (application servers, plugin systems) often add custom class loaders to isolate or hot-swap code, breaking strict delegation intentionally (e.g., to let a web app override a JDK-shipped library version) — this is also the mechanism behind subtle ClassNotFoundException/ClassCastException bugs when the same class gets loaded by two different loaders.