What is unchecked cast and how do I check it?

Question

I think I get what unchecked cast means (casting from one to another of a different type), but what does it mean to \"Check\" the cast? How can I check the cast so that I ca

Answer 1

An unchecked cast, as opposed to checked cast, does not check type safety at runtime.

Here's an example based on the Consider typesafe heterogenous containers section of the 3rd ed. of "Effective Java" by Joshua Bloch, but the container class is intentionally broken - it stores and returns the wrong type:

public class Test {

    private static class BrokenGenericContainer{
        private final Map<Class<?>, Object> map= new HashMap<>();

        public <T> void store(Class<T> key, T value){
            map.put(key, "broken!"); // should've been [value] here instead of "broken!"
        }

        public <T> T retrieve(Class<T> key){
//          return key.cast(map.get(key)); // a checked cast 
            return (T)map.get(key);        // an unchecked cast
        }

    }

    public static void main(String[] args) {
        BrokenGenericContainer c= new BrokenGenericContainer();
        c.store(Integer.class, 42);
        List<Integer> ints = new ArrayList<>();
        ints.add(c.retrieve(Integer.class));
        Integer i = ints.get(0);
    }

}

If the retrieve() uses an unchecked cast -(T)map.get(key) - running this program will lead to ClassCastException occurring at Integer i = ints.get(0) line. The retrieve() method will complete because the actual type was not checked at runtime:

Exception in thread "main" 
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Test.main(Test.java:27)

But if the retrieve() uses a checked cast - key.cast(map.get(key)) - running this program will lead to ClassCastException occurring at key.cast(map.get(key)) line, because the checked cast will find out that the type is wrong and throw the exception. The retrieve() method will not complete:

Exception in thread "main" java.lang.ClassCastException: 
                                          Cannot cast java.lang.String to java.lang.Integer
    at java.lang.Class.cast(Class.java:3369)
    at Test$BrokenGenericContainer.retrieve(Test.java:16)
    at Test.main(Test.java:26)

Little difference it may seem, but in the case with the unchecked cast, a String successfully made its way into a List<Integer>. In real world applications, consequences of this may be... well, severe. In case with the checked cast, the type mismatch was discovered as early as possible.

---

To avoid the unchecked casts warning, @SuppressWarnings("unchecked") can be used, if the programmer is really sure the method is in fact safe. The better alternative is to use generics and checked casts when possible.

As Joshua Bloch put it,

...unchecked warnings are important. Don’t ignore them.

---

For the sake of completeness, this answer deals with the Eclipse specifics.

Answer 2

Unchecked cast means that you are (implicitly or explicitly) casting from a generic type to a nonqualified type or the other way around. E.g. this line

Set<String> set = new HashSet();

will produce such a warning.

Usually there is a good reason for such warnings, so you should try to improve your code instead of suppressing the warning. Quote from Effective Java, 2nd Edition:

Eliminate every unchecked warning that you can. If you eliminate all warnings, you are assured that your code is typesafe, which is a very good thing. It means that you won’t get a ClassCastException at runtime, and it increases your confidence that your program is behaving as you intended.

If you can’t eliminate a warning, and you can prove that the code that provoked the warning is typesafe, then (and only then) suppress the warning with an @SuppressWarnings("unchecked") annotation. If you suppress warnings without first proving that the code is typesafe, you are only giving yourself a false sense of security. The code may compile without emitting any warnings, but it can still throw a ClassCastException at runtime. If, however, you ignore unchecked warnings that you know to be safe (instead of suppressing them), you won’t notice when a new warning crops up that represents a real problem. The new warning will get lost amidst all the false alarms that you didn’t silence.

Of course, it is not always as easy to eliminate warnings as with the code above. Without seeing your code, there is no way to tell how to make it safe though.

Answer 3

To elaborate on what Peter wrote:

Casts from non-generic types to generic types may work just fine at runtime, because the generic parameters are erased during compilation, so we are left with a legitimate cast. However, the code may fail later with an unexpected ClassCastException due to an incorrect assumption regarding the type parameter. For example:

    List l1 = new ArrayList();
    l1.add(33);
    List<String> l2 = (List<String>) l1;
    String s = l2.get(0);

The unchecked warning at line 3 indicates that the compiler is not able to guarantee type safety, in the sense that an unexpected ClassCastException may occur at a later point. Indeed, this happens at line 4, which performs an implicit cast.