Se il mio IDE è così intelligente, perché devo lanciare "clone ()"?

Il mio tipo IDE ( NetBeans ) controlla il mio Collectionsmentre sto scrivendo il codice. Ma allora, perché devo lanciare l'oggetto restituito di Object.clone()? Va bene Nessun danno nessun inganno. Ma ancora non capisco.

Il controllo del tipo, senza casting, Object.clone()non è possibile per l' oggetto restituito ? Il framework generics mi fa pensare che l'IDE potrebbe controllare il tipo di riferimenti a oggetti sul lato destro del segno " = " senza eseguire il casting mentre sto scrivendo? Non capisco

addendum Il
mio caso d'uso era solo che avevo un Calendarcampo privato , pubdate . Stavo per scrivere:

Calendar getPubdate() {
    return pubdate;
}

ma c'è il rischio che l'invoker possa modificare il mio pubdate , quindi ho restituito una copia:

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

Quindi, mi chiedevo perché dovevo fare il cast pubdate.clone(). La firma del metodo ha il tipo proprio lì. NetBeans dovrebbe essere in grado di capirlo. E NetBeans sembrava fare qualcosa di simile riguardo a Collections.

perché devo lanciare l'oggetto restituito di Object.clone()?

Perché ritorna Object.

Il framework generics mi fa pensare che l'IDE potrebbe controllare il tipo di riferimenti a oggetti sul lato destro del segno " = " senza eseguire il casting mentre sto scrivendo? Non capisco

Object.clone non è generico.

Se i generici fossero esistiti quando è clonestato progettato, probabilmente sarebbe stato così (usando il polimorfismo limitato da F):

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

Se Java avesse una funzionalità MyType, potrebbe apparire così:

interface Cloneable {
  this clone();
}

Ma Generics non esisteva quando è Object.clonestato progettato e Java non ha MyTypes, quindi la versione non sicura di tipo Object.cloneè ciò con cui dobbiamo lavorare.

Questa non è una caratteristica di alcun IDE, ma della definizione della lingua.

Un IDE ti aiuta a usare un linguaggio di programmazione in modo più efficiente, non cambia la semantica di quel linguaggio. Ciò significa che un helper editor potrebbe inserire automaticamente un cast quando è ovvio quale desideri, ma non può semplicemente infrangere le regole del linguaggio e fingere che il codice che non viene compilato sia valido.

Modifica È vero che un IDE può raggruppare il proprio compilatore, e in effetti molti lo fanno esattamente, ad esempio per una migliore segnalazione degli errori con più informazioni interne nell'albero di analisi parziale. Tuttavia, sarebbe una pessima idea lasciare che questo compilatore interno implementasse una semantica del linguaggio diversa rispetto all'SDK ufficiale, poiché ciò significherebbe che il codice che funziona nello sviluppo può misteriosamente iniziare a fallire quando installato in produzione - producendo problemi che sono per definizione non- debuggable!

È dovuto alla firma del tipo del metodo Object.clone. La firma del tipo indica che il metodo restituirà un oggetto di tipo Object.

protected Object clone() throws CloneNotSupportedException

Le raccolte utilizzeranno i cosiddetti tipi generici per sostituire automaticamente il tipo di casting.

Quindi se hai questo codice:

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

il compilatore aggiungerà i cast per te dietro le quinte, quindi il codice sarebbe effettivamente:

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

Per completezza, a partire da Java 5, sono consentiti tipi di ritorno covarianti . Quindi puoi scrivere quanto segue:

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

Con questo, il seguente codice è legale:

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