Code10x
Class loadingmedium3-5 years

A production error reads `ClassCastException: Cannot cast plugin.PriceRule to plugin.PriceRule` — the exact same class name on both sides. A teammate assumes it's a build artifact with a stale class file. Is that a reasonable first guess, and what's actually going on?

It's a reasonable first instinct, but it's the wrong mechanism — there's no typo and no stale file. A class's real identity at run time isn't just its name, it's the pair (name, defining class loader): the same .class file loaded by two different loaders produces two genuinely different Class objects that happen to share a name. The cast fails because an object created by loader A's PriceRule is being handed to code expecting loader B's PriceRule — different classes as far as the JVM is concerned, identical strings as far as the error message goes. This shows up in application servers with a library present in both the server and the deployed app, plugin systems, hot-reload tooling, or a dev-mode restart loader holding one copy of a class while something else cached another.

The lesson behind it →
PreviousA service holds five million numbers in a `List<Integer>` and someone proposes switching to `int[]` "to save a bit of overhead." How much memory does that actually save, and why is the answer not obvious from the field types alone?Next A code review comment says "this method allocates a small, short-lived object every call in a hot loop — that's going to hurt GC." Is that always true in Java, and what would you actually check before rewriting the code to avoid the allocation?
More on Class loading
Parent delegation means a class loader asks its parent first, and a parent has no way to ask a child. So how does `DriverManager` — loaded by the bootstrap loader, part of the core JDK — ever find a JDBC driver class that lives in application code, sitting on a child loader several levels below it?