Jeśli moje IDE jest tak inteligentne, dlaczego muszę przesyłać „clone ()”?

Mój typ IDE ( NetBeans ) sprawdza mój Collectionspodczas pisania kodu. Ale dlaczego muszę rzucić zwrócony przedmiot Object.clone()? Co jest w porządku Bez szkody, bez faulu. Ale nadal nie rozumiem.

Czy sprawdzanie typu bez rzutowania zwrócony obiekt Object.clone()jest niemożliwe? Rodzajowych ramy sprawia, że myślę IDE mógł sprawdzić typ referencji obiektu na prawym boku „ = znakiem” bez rzucania gdy piszę? Nie rozumiem

addendum
Mój przypadek użycia polegał na tym, że miałem prywatne Calendarpole, data publikacji . Miałem zamiar napisać:

Calendar getPubdate() {
    return pubdate;
}

ale istnieje ryzyko, że wywołujący może zmodyfikować moją datę publikacji , więc zwróciłem kopię:

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

Potem zastanawiałem się, dlaczego muszę rzucić pubdate.clone(). Podpis metody ma właśnie tam typ. NetBeans powinien być w stanie to rozgryźć. A NetBeans zdawał się robić coś podobnego w odniesieniu do Collections.

dlaczego muszę rzucić zwrócony obiekt Object.clone()?

Ponieważ powraca Object.

Rodzajowych ramy sprawia, że myślę IDE mógł sprawdzić typ referencji obiektu na prawym boku „ = znakiem” bez rzucania gdy piszę? Nie rozumiem

Object.clone nie jest ogólny.

Gdyby istniały leki generyczne, kiedy clonezostały zaprojektowane, prawdopodobnie wyglądałoby to tak (używając polimorfizmu F-Bounded):

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

Gdyby Java miała funkcję MyType, mogłaby wyglądać następująco:

interface Cloneable {
  this clone();
}

Ale Generics nie istniał, kiedy Object.clonezostał zaprojektowany, a Java nie ma MyTypes, więc Object.clonemusimy pracować z niebezpieczną wersją typu .

Nie jest to cecha żadnego IDE, ale definicji języka.

IDE pomaga efektywniej wykorzystywać język programowania, nie zmienia semantyki tego języka. Oznacza to, że pomocnik edytora może automatycznie wstawić rzutowanie, gdy jest oczywiste, który chcesz, ale nie może po prostu złamać reguł języka i udawać, że kod, który się nie kompiluje, jest poprawny.

Edycja Prawdą jest, że IDE może spakować swój własny kompilator, a wielu z nich właśnie to robi, np. W celu lepszego raportowania błędów z większą ilością informacji wewnętrznych w częściowym drzewie analizy. Byłoby jednak bardzo złym pomysłem, aby pozwolić temu wewnętrznemu kompilatorowi na implementację semantyki języka innej niż oficjalny SDK, ponieważ oznaczałoby to, że kod działający w fazie programowania może w tajemniczy sposób przestać działać po zainstalowaniu w środowisku produkcyjnym, powodując problemy, które z definicji są niespójne. debugowalne!

Wynika to z podpisu typu metody Object.clone. Podpis typu stwierdza, że ​​metoda zwróci obiekt typu Object.

protected Object clone() throws CloneNotSupportedException

Kolekcje wykorzystają tak zwane typy ogólne, aby automatycznie zastąpić typ rzutowania.

Więc jeśli masz ten kod:

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

kompilator doda dla Ciebie obsady, więc kod będzie w rzeczywistości:

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

Dla kompletności, od Java 5, dozwolone są typy kowariancji zwracanych . Możesz więc napisać:

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

Dzięki temu następujący kod jest legalny:

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