Why does this recursive generic builder pass javac, but throw a ClassCastException at runtime without any unchecked warnings?

[studioframes]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Java / Compiler & Type Inference

Body

Hey everyone,

I'm working on a fluent API builder using deeply nested Java generics, but I ran into a weird behavior with type inference.

Given the following code:

public class GenericMindmeld {

    interface Wrapper<T> {
        T unwrap();
    }

    static class Box<T> implements Wrapper<T> {
        private final Object value;

        Box(Object value) {
            this.value = value;
        }

        @Override
        @SuppressWarnings("unchecked")
        public T unwrap() {
            return (T) value;
        }
    }

    public static <T extends Wrapper<T>> T resolve(Wrapper<?> wrapper) {
        return ((Wrapper<T>) wrapper).unwrap();
    }

    public static void main(String[] args) {
        // Line A: Compiles cleanly with ZERO warnings
        String result = resolve(new Box<Box<String>>("Hello World"));
        
        System.out.println(result);
    }
}

What I expect:

Either javac should reject Line A with a type mismatch / inference error, or it should print "Hello World".

What actually happens:

It compiles without a single warning, but running it throws:
Exception in thread "main" java.lang.ClassCastException: class GenericMindmeld$Box cannot be cast to class java.lang.String

Is this an edge case bug in how javac handles recursive bounds (T extends Wrapper<T>) against target-type inference, or is this expected behavior according to the JLS? How do I get the compiler to catch this at compile-time?

Guidelines

• I have read and understood this category's guidelines before making this post.

[Albert23867]

Without seeing the code, it's hard to pinpoint the exact issue because this behavior depends on how the recursive generic builder is declared and used.

A ClassCastException with no unchecked warnings often means the compiler was able to verify the generic types at compile time, but type erasure caused a generated cast that only failed at runtime. Another common cause is an incorrect self-referential generic declaration (for example, using an incompatible subtype with an F-bounded generic pattern) or returning the wrong concrete builder type.

Could you share:

The builder class and its generic declaration.
The code that creates and uses the builder.
The complete ClassCastException stack trace.

Those details will make it possible to explain exactly why javac accepted the code and where the runtime cast is failing.

[studioframes]

Hey @Albert23867,

The complete self-contained executable code is actually in the original post body above, but here is the exact minimal snippet isolated again:

public class GenericMindmeld {

    interface Wrapper<T> {
        T unwrap();
    }

    static class Box<T> implements Wrapper<T> {
        private final Object value;

        Box(Object value) {
            this.value = value;
        }

        @Override
        @SuppressWarnings("unchecked")
        public T unwrap() {
            return (T) value;
        }
    }

    public static <T extends Wrapper<T>> T resolve(Wrapper<?> wrapper) {
        return ((Wrapper<T>) wrapper).unwrap();
    }

    public static void main(String[] args) {
        // Compiles with 0 warnings on javac (JDK 17/21), throws CCE at runtime:
        String result = resolve(new Box<Box<String>>("Hello World"));
        System.out.println(result);
    }
}

Full Stack Trace:

Exception in thread "main" java.lang.ClassCastException: class GenericMindmeld$Box cannot be cast to class java.lang.String
    at GenericMindmeld.main(GenericMindmeld.java:24)

No external builder frameworks or third-party libs are used here—it's pure JDK standard library javac behavior with F-bounded generics (T extends Wrapper<T>).

If you copy-paste that single file and run javac GenericMindmeld.java && java GenericMindmeld, you'll see javac passes it completely clean with zero warnings, but line 24 blows up on execution.

Curious to hear your thoughts on why target-type inference assigns T in a way that generates an implicit cast to String at the main callsite!

[ajayxuns]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Java / Compiler & Type Inference

Body

Hi everyone,

I'm experimenting with a fluent API that relies on deeply nested Java generics, and I came across a type inference behavior that surprised me.

Consider the following code:

public class GenericMindmeld {

    interface Wrapper<T> {
        T unwrap();
    }

    static class Box<T> implements Wrapper<T> {
        private final Object value;

        Box(Object value) {
            this.value = value;
        }

        @Override
        @SuppressWarnings("unchecked")
        public T unwrap() {
            return (T) value;
        }
    }

    public static <T extends Wrapper<T>> T resolve(Wrapper<?> wrapper) {
        return ((Wrapper<T>) wrapper).unwrap();
    }

    public static void main(String[] args) {
        // Compiles without warnings
        String result = resolve(new Box<Box<String>>("Hello World"));

        System.out.println(result);
    }
}

Expected behavior

I expected one of the following:

• The compiler rejects the assignment because the inferred type is incompatible with String.
• The program successfully prints Hello World.

Actual behavior

The code compiles without any compiler warnings or errors, but it fails at runtime with:

Exception in thread "main" java.lang.ClassCastException:
GenericMindmeld$Box cannot be cast to java.lang.String

My questions are:

• Is this behavior expected according to the Java Language Specification, or is it a compiler edge case?
• Why does the compiler infer a type that satisfies the recursive bound T extends Wrapper<T> while still allowing assignment to String?
• Is the unchecked cast inside resolve() the only reason this compiles, or is target-type inference involved as well?
• Is there a way to redesign this API so that the compiler rejects this code at compile time instead of allowing a runtime ClassCastException?

Any explanation of the type inference process or references to the relevant JLS sections would be greatly appreciated.

Guidelines

I have read and understood this category's guidelines before making this post.

[DhanushAleti]

The root cause here isn't target-type inference misbehaving — it's that the resolve method's parameter type is the raw type Wrapper (not Wrapper<?> or Wrapper<T>):

public static <T extends Wrapper<T>> T resolve(Wrapper wrapper) {
    return ((Wrapper<T>) wrapper).unwrap();
}

Per JLS 4.8 and 5.1.9, once you reference a generic type through its raw form, javac disables unchecked-warning generation for member accesses/casts performed through that raw reference. That's exactly what happens with ((Wrapper<T>) wrapper) — it IS an unchecked cast (T is erased, so this compiles to a plain (Wrapper) wrapper at bytecode level), but because wrapper's static type is raw Wrapper, the compiler suppresses the warning it would normally emit for that unchecked cast. That's why you see zero warnings even without @SuppressWarnings.

Then at the call site, T is resolved purely by target-type inference from String result = resolve(...), so T=String is chosen because it's consistent with the assignment target and satisfies the recursive bound T extends Wrapper<T> at the type level (nothing checks that the actual runtime object is a Wrapper<String>). The real object is a Box<Box<...>>, so unwrap() returns the boxed value directly ("Hello World" as an Object), and the implicit checkcast the compiler inserts at the call site to convert the inferred T (erased to String) to match String result is what throws the ClassCastException — not inside resolve()/unwrap() at all, but at line 24 in main.

This is expected (if easily-missed) JLS behavior, and it's a classic "raw type disables unchecked warnings" trap — not a compiler bug.

How to make javac actually catch it:

1. Never accept a raw generic type as a parameter. Change the signature to use a wildcard or bounded type so the unchecked cast is no longer masked:
   public static T resolve(Wrapper<?> wrapper) { ... }
   This alone will make the compiler emit the unchecked warning it was suppressing, which is your early-warning signal.
2. Better: avoid the self-bounded <T extends Wrapper<T>> + internal cast pattern entirely. Have unwrap() return Object and force callers to cast explicitly, or use a Class<T> token passed into resolve so you can do a checked cast (type.cast(value)) that fails fast with a clear message at the real point of the type violation instead of silently at an unrelated assignment.
3. If you want compile-time safety with fluent generic builders, consider the classic self-referential generic pattern (abstract class Builder<T extends Builder<T>>) without introducing a raw-typed bridge method — the raw type is what broke type-safety here, not the recursive bound itself.

TL;DR: it's not a javac bug — the raw Wrapper parameter silently disables the unchecked-cast warning that would have flagged this, and target-type inference then picks T=String purely from the assignment context, deferring the real type error to an invisible checkcast at the call site.