Si mon IDE est si intelligent, pourquoi dois-je lancer «clone ()»?

Mon type IDE ( NetBeans ) vérifie mon Collectionspendant que je tape du code. Mais alors, pourquoi dois-je lancer l'objet retourné Object.clone()? Ce qui est bien. Pas de mal, pas de faute. Mais je ne comprends toujours pas.

La vérification de type, sans transtypage, l'objet retourné Object.clone()n'est -elle pas possible? Le cadre générique me fait penser que l'EDI pourrait vérifier le type de références d'objet sur le côté droit de la marque " = " sans transtypage pendant que je tape? Je ne comprends pas.

addendum
Mon cas d'utilisation était juste que j'avais un Calendarchamp privé , pubdate . J'allais écrire:

Calendar getPubdate() {
    return pubdate;
}

mais il y a un risque que l'invocateur puisse modifier ma publication , j'ai donc renvoyé une copie:

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

Ensuite, je me suis demandé pourquoi j'avais besoin de lancer pubdate.clone(). La signature de méthode a le type juste là. NetBeans devrait être capable de comprendre cela. Et NetBeans semblait faire quelque chose de similaire en ce qui concerne Collections.

pourquoi dois-je lancer l'objet retourné Object.clone()?

Parce qu'il revient Object.

Le cadre générique me fait penser que l'EDI pourrait vérifier le type de références d'objet sur le côté droit de la marque " = " sans transtypage pendant que je tape? Je ne comprends pas.

Object.clone n'est pas générique.

Si des génériques avaient existé au moment de la cloneconception, cela aurait probablement ressemblé à ceci (en utilisant le polymorphisme F-Bounded):

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

Si Java avait une fonctionnalité MyType, cela ressemblerait peut-être à ceci:

interface Cloneable {
  this clone();
}

Mais les génériques n'existaient pas au moment de la Object.cloneconception, et Java n'a pas MyTypes, donc la version non sécurisée de type avec Object.clonelaquelle nous devons travailler.

Ce n'est une caractéristique d'aucun IDE, mais de la définition du langage.

Un IDE vous aide à utiliser un langage de programmation plus efficacement, il ne change pas la sémantique de ce langage. Cela signifie qu'un assistant d'édition peut insérer automatiquement un transtypage quand il est évident lequel vous voulez, mais il ne peut pas simplement enfreindre les règles du langage et prétendre que le code qui ne compile pas est valide.

Modifier Il est vrai qu'un IDE peut regrouper son propre compilateur, et en fait, beaucoup le font exactement, par exemple pour un meilleur rapport d'erreurs avec plus d'informations internes dans l'arbre d'analyse partielle. Cependant, ce serait une très mauvaise idée de laisser ce compilateur interne implémenter une sémantique de langage différente de celle du SDK officiel, car cela signifierait que le code qui fonctionne en développement peut mystérieusement commencer à échouer lorsqu'il est installé en production - produisant des problèmes par définition non débogable!

Cela est dû à la signature de type de la méthode Object.clone. La signature de type indique que la méthode retournera un objet de type Object.

protected Object clone() throws CloneNotSupportedException

Les collections utiliseront des types dits génériques pour remplacer automatiquement le type de transtypage.

Donc, si vous avez ce code:

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

le compilateur ajoutera les castes pour vous dans les coulisses, donc le code serait en fait:

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

Par souci d'exhaustivité, depuis Java 5, les types de retour covariants sont autorisés . Vous pouvez donc écrire ce qui suit:

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

Avec cela, le code suivant est légal:

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