ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String (java.lang.Integer and java.lang.String are in module java.base of loader 'bootstrap')

Q: Decode the parenthetical — who is who, and under which loader

When to use: Use this to translate the JDK 9+ message into an immediate verdict.. Grammar: class A cannot be cast to class B (A and B in module M of loader L). Reading direction matters: A is the OBJECT you hold, B is what the cast demanded. Identical classes under DIFFERENT loaders mean the same library shipped twice — fat jar embedding its own copy plus a server-provided copy — and no cast between them can ever succeed. Same loader different classes is plain wrong-type data.

Q: Guard risky casts with instanceof pattern matching

When to use: Use this when the type genuinely varies at runtime (heterogeneous lists, legacy Object APIs).. Since Java 16 the instanceof pattern binds the cast variable in the same breath, removing the cast-crash window entirely. Pre-16 code uses the classic two-step form. Prefer restructuring over guarding when callers control the types.

Q: Let generics carry the typing — beware raw types

When to use: Use this when collections or APIs are involved; raw types defer the blast radius.. Erasure means generics vanish at runtime: a raw List happily stores an Integer even where List was intended, and the ClassCastException detonates LATER — at the read site, often another file entirely. That distance is why the error feels random. Fix every raw-type warning at its source instead of sprinkling casts downstream.

Q: Hunt duplicate classes when loaders differ

When to use: Use this when the parenthetical shows two DIFFERENT loaders or modules for identically-named classes.. Same fully-qualified name under two loaders = the library exists twice on the runtime path (application fat jar AND container-provided lib, or war WEB-INF/lib plus server shared dir). Casts between them fail by design. Find the double packaging with dependency analysis, then exclude or mark provided.

Q: Unwrap lazy proxies before instanceof/casts (JPA)

When to use: Use this when Hibernate entities fail instanceof checks or casts despite looking correct.. Lazy loading substitutes a bytecode subclass proxy (CardPayment$HibernateProxy$...) for the real entity, so instanceof ConcreteType fails even though the row IS that type. Cast to the interface, fetch eagerly, or unwrap explicitly — never force-cast a proxy to the concrete class.

🔴 The Error You're Seeing

Confirm this matches your console output. If it does, you're in the right place.

ERROR LOG

Exception in thread "main" java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String (java.lang.Integer and java.lang.String are in module java.base of loader 'bootstrap')
	at com.devinhyderabad.pay.Billing.labelFor(Billing.java:5)
	at com.devinhyderabad.pay.PayMain.main(PayMain.java:5)

// Application classes show the SAME shape with the unnamed app module:
Exception in thread "main" java.lang.ClassCastException: class com.devinhyderabad.pay.CardPayment cannot be cast to class com.devinhyderabad.pay.UpiPayment (com.devinhyderabad.pay.CardPayment and com.devinhyderabad.pay.UpiPayment are in unnamed module of loader 'app')
	at com.devinhyderabad.pay.CceAppMain.main(CceAppMain.java:6)

// On Java <= 8 the same casts printed only the two class names:
Exception in thread "main" java.lang.ClassCastException: CardPayment cannot be cast to UpiPayment

⚡ Quick Fix Works 80% of the time

Guard the cast with instanceof pattern matching, or eliminate the cast with generics.

// Java 16+: bind the narrowed type in one line
if (value instanceof String s) {
    return s;
}
throw new IllegalArgumentException(
    "expected String, got " + value.getClass().getName());

🧠 Why this Happens

Tap to expand the deep technical explanation

The checkcast bytecode asks the JVM whether the object's actual class (its klass pointer in the object header) is assignable to the demanded type. Assignability consults real class metadata — including WHICH loader defined each class, since identity in the JVM is Class + Loader, not name alone. That is why two classes with identical source can never cast to each other when separate loaders defined them. Since JDK 9, message construction walks both sides' module metadata, producing the parenthetical that turns an opaque crash into a deployment clue. Generics do not participate: erasure erased the type arguments at compile time, so checkcast only sees whatever raw type survives at the use site.

The HITEC City Parking Spot Analogy:

A valet key labeled "Truck" refuses to start a sedan — the metal matches, the ignition system checks what is actually underneath. Post-JDK 9, the car now ALSO tells you which dealership registered each vehicle, revealing when two "identical" cars came from different factories.

🔁 How to Reproduce Confirm this is your error

Cast an autoboxed Integer held as Object to String inside Billing.labelFor(Object) — instant throw. Both modern variants captured verbatim; wording verified byte-identical on OpenJDK 17.0.19 and Temurin 25.0.2. The bare two-name legacy line requires a JDK <= 8 runtime (not installed locally).

🛠️ Solutions (5 Ways to Fix)

Solution 1✓ Most common cause

Decode the parenthetical — who is who, and under which loader

👉 Use this to translate the JDK 9+ message into an immediate verdict.

Grammar: class A cannot be cast to class B (A and B in module M of loader L). Reading direction matters: A is the OBJECT you hold, B is what the cast demanded. Identical classes under DIFFERENT loaders mean the same library shipped twice — fat jar embedding its own copy plus a server-provided copy — and no cast between them can ever succeed. Same loader different classes is plain wrong-type data.

System.out.println(value.getClass().getName()
    + " loaded by " + value.getClass().getClassLoader());
// Duplicate-jar tell: two DIFFERENT loader objects for the SAME FQN

Solution 2

Guard risky casts with instanceof pattern matching

👉 Use this when the type genuinely varies at runtime (heterogeneous lists, legacy Object APIs).

Since Java 16 the instanceof pattern binds the cast variable in the same breath, removing the cast-crash window entirely. Pre-16 code uses the classic two-step form. Prefer restructuring over guarding when callers control the types.

// Java 16+
if (obj instanceof Payment p) return p.charge();

// Pre-Java 16
if (obj instanceof Payment) {
    Payment p = (Payment) obj;
    return p.charge();
}

Solution 3

Let generics carry the typing — beware raw types

👉 Use this when collections or APIs are involved; raw types defer the blast radius.

Erasure means generics vanish at runtime: a raw List happily stores an Integer even where List<String> was intended, and the ClassCastException detonates LATER — at the read site, often another file entirely. That distance is why the error feels random. Fix every raw-type warning at its source instead of sprinkling casts downstream.

List raw = new ArrayList();      // raw type: compiler warns
raw.add(42);                     // accepted silently
for (String s : (List<String>) raw) { } // CCE HERE, far from insert

Solution 4

Hunt duplicate classes when loaders differ

👉 Use this when the parenthetical shows two DIFFERENT loaders or modules for identically-named classes.

Same fully-qualified name under two loaders = the library exists twice on the runtime path (application fat jar AND container-provided lib, or war WEB-INF/lib plus server shared dir). Casts between them fail by design. Find the double packaging with dependency analysis, then exclude or mark provided.

mvn dependency:tree -Dverbose | grep mysql
unzip -l app.jar | grep -i "connector"
# Two copies? exclude the transitive one:
# <exclusions><exclusion><groupId>...</groupId>...</exclusion></exclusions>

Solution 5

Unwrap lazy proxies before instanceof/casts (JPA)

👉 Use this when Hibernate entities fail instanceof checks or casts despite looking correct.

Lazy loading substitutes a bytecode subclass proxy (CardPayment$HibernateProxy$...) for the real entity, so instanceof ConcreteType fails even though the row IS that type. Cast to the interface, fetch eagerly, or unwrap explicitly — never force-cast a proxy to the concrete class.

CardPayment real = (CardPayment)
    Hibernate.unproxy(entity);
// Or design around the interface:
if (entity instanceof Payment p) p.settle();

📋 Version Notes

Java 8

Message is the bare two-class form "X cannot be cast to Y" — no class keyword prefixes, no module/loader parenthetical.

Java 9

JPMS introduces the diagnostic parenthetical naming each side's module and defining loader — the "unnamed module of loader" phrasing enters traces everywhere.

Java 16

Pattern matching for instanceof ships, turning the guard-clause fix into a single line.

Java 21

Wording unchanged since 9 — lab captures byte-compared equal across JDK 17 and JDK 25 runtimes.

🛡️ How to Prevent This Next Time

Keep -Xlint:rawtypes,unchecked warnings fatal in CI, avoid raw types entirely, prefer interfaces over concrete casts across module boundaries, verify single-copy packaging of shared libraries, and unwrap JPA proxies before type checks.