Fix: Java ClassCastException: class X cannot be cast to class Y

The Cast That Lied to the JVM

Personally, this is one of my favorite Java errors to receive because the message tells you exactly what went wrong: object X cannot be type Y. The trap is that the message rarely names the actual cause. Generics erasure, ClassLoader duplication, and Spring proxies can all produce identical-looking messages with very different fixes. I learned to read the modifier qualifiers in the message before reaching for instanceof. You run your Java application and it crashes with:

Exception in thread "main" java.lang.ClassCastException: class com.example.Dog cannot be cast to class com.example.Cat
    at com.example.Main.main(Main.java:15)

Or you see a variation like:

java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer

In modular or container environments, you might encounter the longer form:

java.lang.ClassCastException: class com.example.User (in module app) cannot be cast to class com.example.User (in module lib)

The JVM throws ClassCastException when you try to cast an object to a type it does not belong to. This is a runtime error; the compiler cannot always catch it, especially when generics, raw types, or reflection are involved.

Quick Reference Before You Dive In

If you arrived here from Google with a fresh ClassCastException, the five facts that resolve roughly 90 percent of cases:

1. class X (in module/loader A) cannot be cast to class X (in module/loader B) means TWO ClassLoaders loaded the SAME class. Not a normal cast bug. The Java ClassCastException Javadoc and the JVM Spec on type checking are the canonical references.
2. Use pattern matching for instanceof (Java 16+). if (obj instanceof String s) removes the cast entirely and is impossible to get wrong.
3. In Spring, cast to the INTERFACE, not the implementation. JDK dynamic proxies implement the interface but do not extend the concrete class. (UserServiceImpl) cast on a proxied bean fails; (UserService) works.
4. Raw types are the source of most generic-related ClassCastExceptions. Treat -Xlint:unchecked warnings as errors in the build, never use List without a type parameter.
5. Jackson deserializing to Object.class produces a LinkedHashMap, not the target type. Always pass the explicit class or TypeReference<List<User>> when deserializing.

The rest of this article walks through each cause in detail, plus the failure modes most other guides skip.

Why the Compiler Lets the Cast Through

Java is a strongly typed language. Every object has a concrete type determined at instantiation time. When you write a cast like (Cat) animal, you are telling the JVM: “trust me, this object is a Cat.” If it is not, the JVM throws a ClassCastException instead of allowing corrupted data to propagate silently.

Several common scenarios trigger this error:

• Unsafe downcasting without checking the actual type first.
• Generic type erasure — at runtime, List<String> and List<Integer> are both just List, so the JVM cannot enforce generic types during casting.
• ClassLoader conflicts — two different ClassLoaders load the same class, producing two distinct Class objects that the JVM considers incompatible even though the bytecode is identical.
• Raw types in collections — using unparameterized collections allows any object type to sneak in, causing cast failures when you retrieve elements.
• Incorrect type hierarchies — casting between sibling classes or unrelated interfaces that share no inheritance relationship.
• Serialization round-trips — deserializing an object can produce a type from a different ClassLoader or a different version of the class.
• Spring and DI containers — proxy objects, AOP wrappers, and CGLIB subclasses can cause unexpected type mismatches.

Understanding which scenario applies to your case determines the correct fix.

Diagnostic Timeline

The first reflex is to wrap the cast in instanceof and move on. That hides the bug when the real cause is two copies of the same class loaded by different loaders, or a generic bridge method failing inside compiler-generated code. Spend three minutes confirming the category before changing the cast.

Minute 0: Read the exception message literally. Look for the parenthetical form class com.example.User (in module app) cannot be cast to class com.example.User (in module lib). If the simple names match but the module/loader names differ, you are not in a normal cast bug; skip ahead to the ClassLoader category. If the simple names differ, this is plain type mismatch.

Minute 1: Print the loader of both sides. Insert these two lines immediately before the failing cast:

System.out.println("src loader: " + obj.getClass().getClassLoader()
    + " hash=" + System.identityHashCode(obj.getClass()));
System.out.println("tgt loader: " + Target.class.getClassLoader()
    + " hash=" + System.identityHashCode(Target.class));

If the hash values differ, the JVM is comparing two distinct Class objects with identical bytecode (the ClassLoader category). Go to Fix 3 and stop investigating generics.

Minute 2: If loaders match, walk the class hierarchy. The exception names the source type. Run obj.getClass().getName() and check whether it is a CGLIB/Proxy class name (com.sun.proxy.$Proxy85, ...$$EnhancerBySpringCGLIB$$...). If yes, you are in the Spring-proxy category (Fix 7). If no, check whether the source class implements the target interface or extends the target class. If neither, you are casting between siblings (Fix 5).

Minute 3: If hierarchy looks correct, the bug is in generics. Enable the JVM flags that surface the real problem on the next run:

java -verbose:class -Xlint:unchecked -cp ... com.example.Main 2>&1 | grep example.User

-verbose:class prints every class load event and the loader. If you see [class,load] com.example.User ... from file:.../app.jar twice with different sources, you confirmed duplicate loading from a fat-JAR conflict; see the Still Not Working section. If the load only appears once but the unchecked warnings hit a specific call site, that site is inserting a hidden compiler cast against an Object that was sneaked into a raw collection (Fix 4).

Minute 4: Confirm with one decisive test. Whatever fix you reach for, write a unit test that constructs the exact object graph and asserts the cast succeeds. A passing test is the only proof the category was correct; otherwise you are guessing and will see the same exception in production.

When to Use Which Fix

The next eight sections cover the fixes in detail. The table below maps your situation to the recommended fix.

If multiple rows apply, pick the topmost one.

Fix 1: Use instanceof Before Casting

The most direct cause of ClassCastException is an unguarded downcast. Always verify the type before casting.

Wrong:

Object obj = getResult();
String value = (String) obj; // ClassCastException if obj is not a String

Right:

Object obj = getResult();
if (obj instanceof String) {
    String value = (String) obj;
    System.out.println(value);
} else {
    System.err.println("Unexpected type: " + obj.getClass().getName());
}

This pattern is essential anywhere you receive objects from generic APIs, framework callbacks, or deserialization methods where the return type is Object.

For method parameters, add a guard at the top:

public void process(Object input) {
    if (!(input instanceof MyDto)) {
        throw new IllegalArgumentException(
            "Expected MyDto but got " + input.getClass().getName()
        );
    }
    MyDto dto = (MyDto) input;
    // safe to use dto
}

Throwing IllegalArgumentException with a descriptive message is far more debuggable than letting a raw ClassCastException surface from deep inside your logic.

An observation from code review: a chain of if (x instanceof A) ... else if (x instanceof B) checks almost always means the polymorphism is wrong, not that you need more instanceof guards. The right answer is a shared interface (when behavior is uniform) or sealed types with pattern matching (when behavior differs per case). I treat any third instanceof branch as a signal to redesign rather than to add another else if.

Fix 2: Fix Generic Type Erasure Issues

Java generics are erased at compile time. This means List<String> becomes List in the bytecode, and the JVM has no knowledge of the generic type parameter at runtime. This leads to subtle ClassCastException errors that compile without warnings.

The trap:

List<String> strings = new ArrayList<>();
strings.add("hello");

List rawList = strings; // no warning in older Java, unchecked warning in modern Java
rawList.add(42);        // compiles fine -- raw type bypasses generics

for (String s : strings) { // ClassCastException on the Integer element
    System.out.println(s);
}

The cast to String is inserted by the compiler automatically during iteration. When it hits the Integer value 42, it throws ClassCastException.

Fix this by:

1. Never using raw types. Always parameterize your collections:

List<String> strings = new ArrayList<>();

2. Enabling compiler warnings and treating them as errors in your build:

<!-- Maven -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <compilerArgs>
            <arg>-Xlint:unchecked</arg>
            <arg>-Werror</arg>
        </compilerArgs>
    </configuration>
</plugin>

3. Using Collections.checkedList() for runtime type safety when you must interact with raw-type APIs:

List<String> safeList = Collections.checkedList(new ArrayList<>(), String.class);
safeList.add("hello"); // fine
safeList.add((Object) 42); // throws ClassCastException immediately at insertion

This catches the problem at the point of insertion rather than at retrieval, making debugging far easier.

A related trap: if the unchecked raw-type code stores null instead of a wrong type, you get a NullPointerException on access instead of ClassCastException. The fix is the same: parameterize the collection and validate at the boundary.

Fix 3: Fix ClassLoader Conflicts (Same Class, Different Loaders)

This is one of the most confusing ClassCastException scenarios. The error message looks like:

java.lang.ClassCastException: class com.example.User cannot be cast to class com.example.User

The class name is identical on both sides. This happens because two different ClassLoaders loaded the same .class file, and the JVM treats each loaded version as a distinct type.

Common causes:

• Application servers (Tomcat, WildFly) using separate ClassLoaders per WAR deployment.
• OSGi bundles with mismatched imports/exports.
• Custom ClassLoaders in plugin architectures.
• Hot-reloading tools like Spring DevTools creating a restart ClassLoader.

Diagnose it by printing the ClassLoader of both sides:

System.out.println("Source ClassLoader: " + obj.getClass().getClassLoader());
System.out.println("Target ClassLoader: " + User.class.getClassLoader());

If these print different ClassLoader instances, you have confirmed the problem.

Fix strategies:

1. Move the shared class to a parent ClassLoader. In application servers, place the JAR in the server’s shared lib directory (e.g., $CATALINA_HOME/lib for Tomcat) so both deployments use the same ClassLoader.

2. In Spring Boot with DevTools, exclude problematic classes from the restart ClassLoader:

# application.properties
spring.devtools.restart.exclude=com/example/shared/**

3. Use interfaces from a common module. Instead of casting to a concrete class, cast to an interface loaded by a parent ClassLoader:

// Interface in shared module (parent ClassLoader)
public interface Identifiable {
    String getId();
}

// Cast to interface instead of concrete class
Identifiable entity = (Identifiable) obj;

This pattern is also relevant when dealing with ClassNotFoundException errors, which share the same ClassLoader root causes.

Fix 4: Fix Collection Raw Types (List vs List<String>)

Raw types are the single biggest source of ClassCastException in legacy Java codebases. When you use List instead of List<String>, the compiler cannot enforce what goes into the collection.

The problem in legacy code:

// Old method returns raw List
public List getUsers() {
    List users = new ArrayList();
    users.add(new User("Alice"));
    users.add("not a user"); // compiles fine with raw type
    return users;
}

// Caller assumes List<User>
List<User> users = getUsers(); // unchecked assignment
for (User u : users) { // ClassCastException on "not a user"
    System.out.println(u.getName());
}

Fix this by adding generics to the legacy method:

public List<User> getUsers() {
    List<User> users = new ArrayList<>();
    users.add(new User("Alice"));
    // users.add("not a user"); // now a compile error
    return users;
}

If you cannot modify the legacy code (e.g., a third-party library), filter the list safely:

List<?> rawList = legacyApi.getResults();
List<User> users = new ArrayList<>();
for (Object item : rawList) {
    if (item instanceof User) {
        users.add((User) item);
    } else {
        log.warn("Skipping unexpected type: {}", item.getClass().getName());
    }
}

For Map types, the same pattern applies:

// Wrong
Map config = loadConfig(); // raw type
String value = (String) config.get("timeout"); // ClassCastException if value is Integer

// Right
Map<String, Object> config = loadConfig();
Object raw = config.get("timeout");
if (raw instanceof String s) {
    // use s
} else if (raw instanceof Integer i) {
    // use i
}

Fix 5: Use Proper Type Hierarchies (Interfaces, Abstract Classes)

ClassCastException often reveals a design problem. If you are casting between sibling classes, no amount of runtime checking fixes the architectural issue.

Wrong — casting between siblings:

class Animal {}
class Dog extends Animal {}
class Cat extends Animal {}

Animal animal = new Dog();
Cat cat = (Cat) animal; // ClassCastException: Dog cannot be cast to Cat

Dog and Cat are siblings in the hierarchy. A Dog instance will never be a Cat, regardless of any runtime conditions.

Fix by programming to interfaces:

interface Feedable {
    void feed(String food);
}

class Dog extends Animal implements Feedable {
    public void feed(String food) { /* ... */ }
}

class Cat extends Animal implements Feedable {
    public void feed(String food) { /* ... */ }
}

// No casting needed
Feedable pet = getPet();
pet.feed("kibble");

When you need type-specific behavior, use the visitor pattern or sealed classes (Java 17+) instead of casting:

sealed interface Shape permits Circle, Rectangle {}
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}

double area(Shape shape) {
    return switch (shape) {
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.width() * r.height();
    };
}

Sealed classes combined with pattern matching eliminate the need for explicit casts entirely. The compiler verifies exhaustiveness, so you cannot miss a case.

This kind of type-safety issue is conceptually related to NoSuchMethodError, where the JVM expects one method signature but finds another at runtime.

Fix 6: Fix Serialization/Deserialization Casts

Serialization introduces ClassCastException in two ways: the deserialized object might be a different type than expected, or it might be loaded by a different ClassLoader.

JSON deserialization (Jackson):

ObjectMapper mapper = new ObjectMapper();
// Wrong: assuming the JSON always maps to User
User user = mapper.readValue(json, User.class); // works

// But if the JSON structure doesn't match:
Object result = mapper.readValue(json, Object.class);
User user = (User) result; // ClassCastException -- result is a LinkedHashMap

Jackson deserializes to LinkedHashMap when the target type is Object. Fix this by always specifying the correct target type:

User user = mapper.readValue(json, User.class);

// For collections, use TypeReference:
List<User> users = mapper.readValue(json, new TypeReference<List<User>>() {});

Java native serialization:

ObjectInputStream ois = new ObjectInputStream(new FileInputStream("data.ser"));
User user = (User) ois.readObject(); // ClassCastException if class changed

This fails when the serialized class has a different serialVersionUID or when the deserializing JVM uses a different ClassLoader. Fix it by:

1. Explicitly declaring serialVersionUID:

public class User implements Serializable {
    private static final long serialVersionUID = 1L;
    // fields...
}

2. Adding an instanceof check before casting:

Object obj = ois.readObject();
if (obj instanceof User user) {
    // safe to use
} else {
    throw new IllegalStateException("Expected User, got " + obj.getClass().getName()
        + " from ClassLoader " + obj.getClass().getClassLoader());
}

A specific Jackson trap I have walked into more than once: polymorphic deserialization without @JsonTypeInfo / @JsonSubTypes. Jackson defaults the target type to a LinkedHashMap and the cast at the call site explodes with a confusing message. Always annotate polymorphic hierarchies, or restructure the API so each endpoint returns a single concrete type.

Fix 7: Fix Spring Bean Casting Errors

Spring applications encounter ClassCastException due to proxy objects. Spring creates proxies for beans that use @Transactional, @Async, @Cacheable, or AOP aspects. These proxies may not be castable to the concrete class.

The error typically looks like:

java.lang.ClassCastException: class com.sun.proxy.$Proxy85 cannot be cast to class com.example.UserServiceImpl

Why it happens: Spring creates JDK dynamic proxies by default, which implement the bean’s interfaces but do not extend its concrete class. When you inject and cast to the implementation class, it fails.

Fix 1: Cast to the interface, not the implementation:

// Wrong
@Autowired
private UserServiceImpl userService; // fails if proxied

// Right
@Autowired
private UserService userService; // interface type works with proxies

Fix 2: Force CGLIB proxies if you must use the concrete type:

@SpringBootApplication
@EnableAspectJAutoProxy(proxyTargetClass = true)
public class Application { }

Or in application.properties:

spring.aop.proxy-target-class=true

Note: Spring Boot 2.0+ uses CGLIB proxies by default, so this issue is more common in older Spring Framework applications or when using @EnableAsync or @EnableCaching which may override the proxy strategy.

Fix 3: Check your @Bean method return types:

// Wrong: returns concrete type but Spring proxies it
@Bean
public UserServiceImpl userService() {
    return new UserServiceImpl();
}

// Right: return the interface type
@Bean
public UserService userService() {
    return new UserServiceImpl();
}

If you are encountering class loading issues with Spring in general, check whether UnsupportedClassVersionError applies — it signals a JDK version mismatch that can compound proxy-related problems.

Fix 8: Use Pattern Matching for instanceof (Java 16+)

Java 16 introduced pattern matching for instanceof, which eliminates the need for separate cast statements. This makes ClassCastException structurally impossible in code that uses it.

Old style (pre-Java 16):

if (obj instanceof String) {
    String s = (String) obj; // redundant cast
    System.out.println(s.length());
}

New style (Java 16+):

if (obj instanceof String s) {
    System.out.println(s.length()); // s is already cast and scoped
}

The variable s is only in scope inside the if block, and it is guaranteed to be a String. No explicit cast, no risk of ClassCastException.

Use it in combination with logical operators:

if (obj instanceof String s && s.length() > 5) {
    // s is safely cast AND has length > 5
}

Pattern matching in switch (Java 21+):

Object obj = getData();

String result = switch (obj) {
    case Integer i -> "Integer: " + i;
    case String s  -> "String: " + s;
    case Double d  -> "Double: " + d;
    case null      -> "null";
    default        -> "Unknown: " + obj.getClass().getName();
};

This is the modern replacement for chains of instanceof checks followed by casts. The compiler ensures the patterns are exhaustive (with default), and each branch has a properly typed variable.

Migrate existing code gradually. Search your codebase for the old pattern:

grep -rn "instanceof.*\b\w\+\b)" --include="*.java" src/

Then refactor each match to use the binding variable syntax. If you are still on Java 11 or 8, you cannot use this feature; focus on Fixes 1 through 7 instead.

For teams maintaining concurrent Java applications, combining safe casting with proper collection handling avoids both ClassCastException and ConcurrentModificationException during iteration.

Stranger Causes I Have Tracked Down

If you have tried the fixes above and still see ClassCastException, check these less obvious causes:

• Maven-shaded class with relocated package: A shaded dependency renames its packages (com.example.User becomes com.example.shaded.User) but a downstream consumer was compiled against the unshaded name. The cast targets one package and the runtime object lives in the other. Inspect the JAR with jar tf and grep for both names.

• Records replacing legacy classes: When you migrate a class to a record, deserialized payloads from the old class shape may load via reflection but fail to cast. Records have a synthesized canonical constructor and a different runtime layout; re-serialize all stored data after the migration or write an adapter.

• JPMS module readability: In Java 9+, two modules can export the same package only through specific opens/exports directives. A reflective cast across module boundaries without a proper --add-opens flag throws ClassCastException even when the bytecode is identical.

• Hot-reload tools: Spring DevTools, JRebel, and similar tools create new ClassLoaders on reload. Restart the application fully to rule this out.

• Fat JAR conflicts: If you package a fat/uber JAR, duplicate classes from different dependencies can shadow each other. Run mvn dependency:tree or gradle dependencies and look for conflicting versions of the same library.

• Reflection and Class.forName(): When you load classes via reflection, the ClassLoader context matters. Use Thread.currentThread().getContextClassLoader().loadClass() instead of Class.forName() in container environments.

• JNDI lookups: Objects retrieved via JNDI in application servers may come from a different ClassLoader. Cast to interfaces defined in a shared ClassLoader rather than implementation classes.

• Kotlin/Scala interop: If you mix Kotlin or Scala with Java, be aware that Kotlin’s as operator and Scala’s .asInstanceOf[] throw ClassCastException the same way. Use as? in Kotlin (safe cast) or pattern matching in Scala.

• Check the full stack trace: The line number in the stack trace tells you exactly which cast failed. If it points to compiler-generated code (lambda or generic bridge method), the real issue is the generic type mismatch at the point where the object entered the collection or callback.

• Enable verbose class loading for ClassLoader debugging:

java -verbose:class -jar myapp.jar 2>&1 | grep "com.example.User"

This prints every class load event, showing which ClassLoader loaded each class and from which JAR file.

What Other Tutorials Get Wrong About This Error

Most Java tutorials list the same fixes but frame them in ways that produce subtle bugs.

They jump straight to instanceof. That helps for unguarded downcasts but masks the deeper categories (ClassLoader duplication, Spring proxies, generic bridge methods). Read the exception message qualifiers FIRST; instanceof is only the right answer for one of the categories.

They miss the modifier-name distinction. class X cannot be cast to class X with module / loader qualifiers is a completely different bug from class A cannot be cast to class B. Tutorials that show one case as representative leave readers staring at fixes that do not apply to their actual error.

They recommend Casts to concrete classes for Spring beans. Spring’s default JDK dynamic proxies do not extend concrete classes. Articles that inject @Autowired UserServiceImpl produce intermittent failures depending on whether the bean is proxied (transactions, async, AOP). Always inject by interface.

They omit Collections.checkedList. When you must interact with raw-type legacy APIs, checkedList catches the wrong-type insertion at the point of insertion, not on iteration. Articles that focus only on parameterizing your own collections miss this defensive boundary tool.

They miss pattern matching for instanceof. Java 16+ lets you write if (obj instanceof String s) and bind without a separate cast. Tutorials that show the old if ... cast form (and call it idiomatic) train readers to write code that is structurally easier to get wrong.

They confuse ClassCastException with NoSuchMethodError. Both involve runtime type mismatches, but the fixes are different. ClassCastException is about object identity vs cast target; NoSuchMethodError is about method signature mismatch in the loaded class. Tutorials that group them under “binary incompatibility” miss the distinct fixes.

Frequently Asked Questions

Why does class com.example.User cannot be cast to class com.example.User happen?

Two ClassLoaders loaded the same class file. The JVM treats the resulting Class objects as distinct types. Common in application servers (per-WAR loaders), OSGi, Spring DevTools restart loaders, and fat-JAR conflicts. The fix is to move the shared class to a parent loader, exclude it from the restart loader, or cast to an interface defined in a shared module.

Why does my Spring bean cast to the concrete class fail?

Spring creates a JDK dynamic proxy for beans that use @Transactional, @Async, @Cacheable, or AOP aspects. The proxy implements the interfaces but does NOT extend the concrete class. Cast to the interface (UserService), or set @EnableAspectJAutoProxy(proxyTargetClass = true) to force CGLIB proxies that DO extend the concrete class.

Should I use instanceof or pattern matching?

Pattern matching (Java 16+) when available. if (obj instanceof String s) is both shorter and impossible to get wrong (the variable s is automatically the correct type and only in scope where the check passed). For Java 11 or 8 codebases, classic instanceof + cast is fine.

Why does generic code throw ClassCastException even though it compiled?

Generic type information is erased at runtime. List<String> and List<Integer> are both just List to the JVM. Raw types and reflection can sneak wrong-typed values into a collection; the compiler-inserted cast at the retrieval site then fails. Treat -Xlint:unchecked warnings as errors and never use raw types.

Does LinkedHashMap mean my JSON is broken?

No, it means Jackson deserialized to the default type because you did not specify a target. mapper.readValue(json, Object.class) always returns LinkedHashMap for JSON objects. Pass the explicit class (User.class) or new TypeReference<List<User>>() {} for collections.

Why does the same code work in tests but fail in production?

Different ClassLoader setup. Production may run under an application server (Tomcat, WildFly) or with hot-reload tools (Spring DevTools, JRebel) that create separate loaders. The test JVM has a single loader. Reproduce with the exact production startup command, not just the test runner.