Java: why is casting possible on wildcard collections?

Question

Suppose we have a class A, and a class B, which inherits from class A. Let's say we have:

Set<A> setOfAs = new HashSet<>();

The following casting:

((Set<B>) setOfAs)

will give us run-time error.

However, if we use wildcard and define the following set:

Set<? extends A> setOfAs = new HashSet<>();

we have no problem to do the casting:

((Set<B>) setOfAs)

Why casting a collection of a wildcard is allowed, while casting a collection of "regular" type is forbidden?

Does this answer your question? [Most efficient way to cast List to List](https://stackoverflow.com/questions/5082044/most-efficient-way-to-cast-listsubclass-to-listbaseclass) — Frighi, Jun 25 '20 at 09:05
"We have no problem" you have an unchecked cast, don't you? A `Set extends A>` *could be* a `Set`; but a `Set` can't also be a `Set`. — Andy Turner, Jun 25 '20 at 09:08
*"will give us a run-time error"* — I think you meant a *compile-time* error. — MC Emperor, Jun 25 '20 at 09:18
In short: in the first code snippet, the compiler knows that the code is always wrong (i.e. `Set` can never be cast to a `Set`); in the second code snippet, there could be a situation where this is valid, so the compiler only warns, but does not emit an error. — MC Emperor, Jun 25 '20 at 09:32

Andy Turner · Accepted Answer · 2020-06-29T06:04:32.933

we have no problem to do the casting:

You will have an unchecked cast warning, so it's not really the case that you have no problem; it's just that the compiler can't prove it's definitely wrong, and can't put anything into the bytecode to catch the fact it is wrong at runtime.

A Set<? extends T> is a Set where it can be assumed that all members can be safely cast to T without a ClassCastException.

A Set<? super T> would be a Set where it is known to be safe to add a T to it without causing a ClassCastException in places relying on the type of elements in the Set (I believe the correct technical term for this is without causing heap pollution).

A Set<T> is the intersection of these two bounded types: you can add instances of T to it, and all elements in it are instances of T.

By these definitions, a Set can act as a Set<? extends A>, because anything that can be cast to an B can also be cast to A.

However, a Set<A> cannot act as a Set, because it may contain instances of A which aren't instances of B.

score 3 · Answer 2 · answered Jun 25 '20 at 09:15

The whole idea of casting is saying "I know more than you, compiler!" when there's some uncertainty about the actual type of an object.

In the second case, this makes total sense. The compiler knows that setOfAs is of type Set<? extends A>, which means "a Set of an unknown type, and that unknown type extends A". There's uncertainty as to what type of HashSet it could be. As far as the the compiler is concerned, it could be HashSet...

Set<? extends A> setOfAs = new HashSet<A>();

but it also could be HashSet<A>...

Set<? extends A> setOfAs = new HashSet<B>();

You, by means of casting, say "No, setOfAs is a HashSet". The compiler goes, "Well, it could be that, so I'll trust you". Whether your extra knowledge is actually correct, is a separate matter.

In the first case however, setofAs is of type HashSet<A>. Since a variable of type HashSet<A> can never store an object of type HashSet, i.e. this does not compile:

Set<A> setOfAs = new HashSet<B>();

There is no uncertainty about the generic parameter of Set. It's gotta be A. You, trying to cast to HashSet, will only result in the compiler saying "No, it can never be that!"

Java: why is casting possible on wildcard collections?

2 Answers2