Que projetos Java são explicitamente feito para compatibilidade com versões anteriores de apoio? [fechadas]

Question

Desde esta questão está de volta a quatro votos a perto, eu estou tentando novamente para fazer uma pergunta mais estreita que esperamos que a comunidade irá ver mais favorável.

Que decisões de design específicos em Java são documentadas para ser feito da maneira que eles não são, porque essa era a decisão de design preferido, mas sim porque era necessário para suportar compatibilidade com versões anteriores.

O caso óbvio é genéricos, onde você não pode detectar o tipo de parâmetro em tempo de execução. (Então você não pode fazer:

 public void addEmptyMember(List<?> someList) {
      if (someList instanceof List<String>) {
            ((List<String>) someList).add("");
      }
 }

O que existem outros exemplos no projeto de linguagem e API padrão?

Answer 1

Uma vez que esta questão não tem uma única resposta certa, eu não tenho certeza se ele vai se sair melhor do que sua outra pergunta.

três características que eu posso pensar (para além de apagamento genérico, que você já mencionado) que fizeram compromissos em nome da compatibilidade com versões anteriores foram o novo para a sintaxe loop, varargs e autoboxing.

O novo para a sintaxe de loop provavelmente deve ter for (item in List) leitura, mas que teria exigido fazendo in em uma palavra reservada. Isto causou problemas de compatibilidade numerosos para trás, não menos do que é o fato de que System.in teria que ser renomeado.

varargs e autoboxing ambos adicionados as possibilidades de ambiguidade. Por exemplo, se você passar uma matriz de objetos a um método que aceita Object... isso significa que a matriz deve ser passado como a matriz vararg ou como um elemento da matriz vararg? Isso fica ainda mais complicado se há sobrecargas. Autoboxing tem problemas de ambigüidade semelhantes com sobrecarga. A solução para ambos os problemas foi para torná-lo uma regra que ao resolver chamadas de método que eles são primeiramente resolvidas com as regras pré-1,5 (ou seja: não autoboxing e Object... é tratado como Object[]). Só se a chamada de método não pode ser resolvido com as versões anteriores à 1.5-regras são as novas regras 1,5 consideradas.

Answer 2

Existem muitos exemplos na biblioteca padrão

• java.awt.Color tem as mesmas constantes com nomes maiúsculas e minúsculas
• Todos os métodos depreciado em java.util.Date dadas a introdução de java.util.Calendar - que confusão !!
• java.util.Enumeration ainda está sendo usado onde java.util.Iterator poderia substituí-lo
• Classes em balanço que aceitam vetores como argumentos, mas poderia ter tido suporte adicional para java.util.Collection

Answer 3

Outra seria todas as classes e métodos que são preteridos para várias versões até agora, mas simplesmente não vai embora. Mais notáveis ??são os vários métodos Linha, que são obsoletas.

Answer 4

compatibilidade e genéricos Backward