¿Qué es un cast sin marcar y cómo lo compruebo?

Para elaborar más sobre lo que Pedro escribió:

Los casts de tipos no genéricos a tipos genéricos pueden funcionar bien en tiempo de ejecución, porque los parámetros genéricos se borran durante la compilación, por lo que nos queda un cast legítimo. Sin embargo, el código puede fallar más tarde con una inesperada ClassCastException debido a una suposición incorrecta con respecto al parámetro type. Por ejemplo:

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

La advertencia sin marcar en la línea 3 indica que el compilador no puede garantizar la seguridad del tipo más, en el sentido de que una inesperada ClassCastException puede ocurrir más tarde. Y esto sucede en la línea 4, que realiza un molde implícito.

Un cast sin marcar, a diferencia de cast marcado, no comprueba la seguridad de tipo en tiempo de ejecución.

Aquí hay un ejemplo basado en la sección Consider typesafe heterogenous containers de la 3a ed. de "Effective Java" por Joshua Bloch, pero la clase container se rompe intencionalmente - almacena y devuelve el tipo incorrecto:

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);
    }

}

Si el retrieve() utiliza un fundido sin marcar -(T)map.get(key) - ejecutar este programa llevará a ClassCastException que ocurra en la línea Integer i = ints.get(0). El método retrieve() se completará porque el tipo real no se comprobó en tiempo de ejecución:

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

Pero si el retrieve() utiliza un marcado cast - key.cast(map.get(key)) - ejecutar este programa llevará a ClassCastException que ocurra en la línea key.cast(map.get(key)), porque el cast marcado descubrirá que el tipo es incorrecto y lanzará la excepción. El método retrieve() no se completará:

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)

Puede parecer poca diferencia, pero en el caso del reparto sin control, a String se abrió camino con éxito en a List<Integer>. En aplicaciones del mundo real, consecuencias de esto puede ser... bueno, severo. En caso de que el molde marcado, el desajuste de tipo se descubrió lo antes posible.

Para evitar la advertencia de casts sin marcar, se puede usar @SuppressWarnings("unchecked"), si el programador está realmente seguro de que el método es seguro. La mejor alternativa es usar genéricos y yesos revisados cuando sea posible.

Como Joshua Bloch lo puso, {[18]]}

...las advertencias sin marcar son importantes. No los ignores.

En aras de la exhaustividad, esta respuesta trata de los detalles del Eclipse.