Si mi IDE es tan inteligente, ¿por qué necesito lanzar "clone ()"?

Mi tipo IDE ( NetBeans ) comprueba mi Collectionsmientras escribo código. Pero entonces, ¿por qué tengo que lanzar el objeto devuelto Object.clone()? Lo cual está bien. Sin daño no hay falta. Pero aún así, no entiendo.

¿Es posible la verificación de tipos, sin conversión, del objeto devuelto Object.clone()? El marco genérico me hace pensar que el IDE podría verificar el tipo de referencias a objetos en el lado derecho de la marca " = " sin emitir mientras escribo. No lo entiendo

Anexo
Mi caso de uso fue solo que tenía un Calendarcampo privado , pubdate . Yo iba a escribir:

Calendar getPubdate() {
    return pubdate;
}

pero existe el riesgo de que el invocador pueda modificar mi publicación , por lo que devolví una copia:

Calendar getPubdate() {
    return (Calendar) pubdate.clone();
}

Entonces, me pregunté por qué necesitaba lanzar pubdate.clone(). La firma del método tiene el tipo allí mismo. NetBeans debería ser capaz de resolverlo. Y NetBeans parecía estar haciendo algo similar con respecto a Collections.

¿Por qué tengo que lanzar el objeto devuelto Object.clone()?

Porque vuelve Object.

El marco genérico me hace pensar que el IDE podría verificar el tipo de referencias a objetos en el lado derecho de la marca " = " sin emitir mientras escribo. No lo entiendo

Object.clone No es genérico.

Si los genéricos hubieran existido cuando clonese diseñó, probablemente se habría visto así (usando el polimorfismo limitado por F):

interface Cloneable<T extends Cloneable<T>> {
  T clone();
}

Si Java tuviera una función MyType, quizás se vería así:

interface Cloneable {
  this clone();
}

Pero los genéricos no existían cuando Object.clonese diseñó, y Java no tiene MyTypes, por lo que la versión insegura de tipo Object.clonees con lo que tenemos que trabajar.

Esta no es una característica de ningún IDE, sino de la definición del lenguaje.

Un IDE lo ayuda a usar un lenguaje de programación de manera más eficiente, no cambia la semántica de ese lenguaje. Eso significa que un asistente de editor puede insertar automáticamente un reparto cuando sea obvio cuál desea, pero no puede simplemente romper las reglas del lenguaje y pretender que el código que no se compila es válido.

Editar Es cierto que un IDE puede agrupar su propio compilador, y de hecho muchos hacen exactamente eso, por ejemplo, para un mejor informe de errores con más información interna en el árbol de análisis parcial. Sin embargo, sería una muy mala idea dejar que este compilador interno implemente una semántica de lenguaje diferente que el SDK oficial, ya que eso significaría que el código que funciona en el desarrollo puede comenzar a fallar misteriosamente cuando se instala en producción, produciendo problemas que, por definición, no son depurable!

Se debe a la firma de tipo del método Object.clone. La firma de tipo indica que el método devolverá un objeto de tipo Objeto.

protected Object clone() throws CloneNotSupportedException

Las colecciones utilizarán los llamados tipos genéricos para sustituir el tipo de conversión automáticamente.

Entonces, si tienes este código:

List<Integer> ints = Arrays.asList(1,2,3);
int x = ints.get(0);`

el compilador agregará los moldes detrás de escena, por lo que el código en realidad sería:

List ints = Arrays.asList(1,2,3);
int x = (Integer)ints.get(0);

Para completar, desde Java 5, se permiten tipos de retorno covariantes . Entonces puedes escribir lo siguiente:

public MyObject implements Cloneable {
  @Override
  public MyObject clone() {
    try {
      return (MyObject)super.clone();
    } catch (CloneNotSupportedException e) {
      throw new AssertionError();
    }
  }
}

Con esto, el siguiente código es legal:

MyObject original = new MyObject();
MyObject clone = original.clone();