Se meu IDE é tão inteligente, por que preciso converter "clone ()"?

Meu tipo de IDE ( NetBeans ) verifica meu Collectionscódigo enquanto estou digitando. Mas então, por que tenho que lançar o objeto retornado Object.clone()? O que é bom. Nenhum dano, nenhuma falta. Mas ainda assim, eu não entendo.

A verificação de tipo, sem conversão, o objeto retornado Object.clone()não é possível? A estrutura de genéricos me faz pensar que o IDE poderia verificar o tipo de referência de objeto no lado direito da marca " = " sem transmitir enquanto estou digitando? Eu não entendo.

adendo
Meu caso de uso foi justamente porque eu tinha um Calendarcampo privado , pubdate . Eu ia escrever:

Calendar getPubdate() {
    return pubdate;
}

mas existe o risco de o invocador poder modificar meu pubdate , então retornei uma cópia:

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

Então, eu me perguntava por que eu precisava lançar pubdate.clone(). A assinatura do método tem o tipo ali. O NetBeans deve ser capaz de descobrir isso. E o NetBeans parecia estar fazendo algo semelhante em relação a Collections.

por que eu tenho que converter o objeto retornado Object.clone()?

Porque ele retorna Object.

A estrutura de genéricos me faz pensar que o IDE poderia verificar o tipo de referência de objeto no lado direito da marca " = " sem transmitir enquanto estou digitando? Eu não entendo.

Object.clone não é genérico.

Se os genéricos existissem quando cloneforam projetados, provavelmente seria assim (usando o polimorfismo com limite de F):

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

Se o Java tivesse um recurso MyType, talvez fosse assim:

interface Cloneable {
  this clone();
}

Mas os genéricos não existiam quando Object.cloneforam projetados e o Java não possui MyTypes; portanto, Object.cloneé com a qual devemos trabalhar a versão não segura do tipo .

Este não é um recurso de nenhum IDE, mas da definição de linguagem.

Um IDE ajuda você a usar uma linguagem de programação com mais eficiência, não altera a semântica dessa linguagem. Isso significa que um ajudante de editor pode inserir automaticamente uma conversão quando for óbvio qual você deseja, mas não pode simplesmente quebrar as regras da linguagem e fingir que o código que não compila é válido.

Editar É verdade que um IDE pode agrupar seu próprio compilador e, de fato, muitos fazem exatamente isso, por exemplo, para obter melhores relatórios de erros com mais informações internas na árvore de análise parcial. No entanto, seria uma péssima idéia permitir que esse compilador interno implemente semântica de idioma diferente do SDK oficial, pois isso significaria que o código que funciona no desenvolvimento pode misteriosamente começar a falhar quando instalado na produção - produzindo problemas que, por definição, são debuggable!

Isso ocorre devido à assinatura de tipo do método Object.clone. A assinatura de tipo indica que o método retornará um objeto do tipo Object.

protected Object clone() throws CloneNotSupportedException

As coleções usarão os chamados tipos genéricos para substituir automaticamente o tipo de conversão.

Então, se você tem este código:

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

o compilador adicionará os lançamentos para você nos bastidores, para que o código seja realmente:

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

Para ser completo, desde o Java 5, tipos de retorno covariantes são permitidos . Então você pode escrever o seguinte:

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

Com isso, o seguinte código é legal:

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