Если моя IDE такая умная, зачем мне приводить «clone ()»?

Мой тип IDE ( NetBeans ) проверяет мой, Collectionsпока я набираю код. Но тогда, почему я должен бросить возвращенный объект Object.clone()? Что хорошо. Нет вреда, нет фола. Но все же я не понимаю.

Является ли проверка типов без приведения возвращаемого объекта Object.clone()невозможной? Дженерики структура заставляет меня думать IDE может проверить тип ссылок на объекты на правой стороне « = марки» без литья в то время как я печатаю? Я не понимаю

Приложение
Мой случай использования состоял в том, что у меня было личное Calendarполе, pubdate . Я собирался написать:

Calendar getPubdate() {
    return pubdate;
}

но есть риск, что вызывающий может изменить мою публикацию , поэтому я вернул копию:

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

Затем я удивился, почему мне нужно было сыграть pubdate.clone(). Подпись метода имеет тип прямо здесь. NetBeans должен быть в состоянии понять это. И NetBeans, похоже, делал что-то подобное в отношении Collections.

почему я должен бросить возвращенный объект Object.clone()?

Потому что это возвращается Object.

Дженерики структура заставляет меня думать IDE может проверить тип ссылок на объекты на правой стороне « = марки» без литья в то время как я печатаю? Я не понимаю

Object.clone не является общим.

Если бы дженерики существовали, когда они cloneбыли разработаны, это, вероятно, выглядело бы так (используя F-ограниченный полиморфизм):

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

Если бы в Java была функция MyType, она могла бы выглядеть так:

interface Cloneable {
  this clone();
}

Но Generics не существовало, когда она Object.cloneбыла разработана, и у Java нет MyTypes, поэтому Object.cloneнам приходится работать с небезопасной версией типа .

Это не особенность какой-либо IDE, но определение языка.

IDE помогает вам более эффективно использовать язык программирования, но не меняет семантику этого языка. Это означает, что помощник редактора может автоматически вставить приведение, когда очевидно, какой вы хотите, но он не может просто нарушать правила языка и делать вид, что код, который не компилируется, действителен.

Редактировать Это правда, что IDE может связывать свой собственный компилятор, и на самом деле многие делают именно это, например, для лучшего сообщения об ошибках с большей внутренней информацией в частичное дерево разбора. Однако было бы очень плохой идеей позволить этому внутреннему компилятору реализовывать семантику языка, отличную от официального SDK, поскольку это означало бы, что код, работающий в разработке, может таинственным образом начать сбой при установке в производство, что порождает проблемы, которые по определению не отладка!

Это связано с сигнатурой типа метода Object.clone. Сигнатура типа утверждает, что метод вернет объект типа Object.

protected Object clone() throws CloneNotSupportedException

Коллекции будут использовать так называемые универсальные типы для автоматической замены типа приведения.

Так что, если у вас есть этот код:

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

компилятор добавит приведенные для вас закулисные действия, поэтому код будет на самом деле:

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

Для полноты, начиная с Java 5, допускаются ковариантные возвращаемые типы . Таким образом, вы можете написать следующее:

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

При этом допустим следующий код:

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