Quelles sont les conceptions Java sont faites explicitement pour soutenir la rétrocompatibilité? [fermé]

Question

Depuis cette question est de retour à quatre voix pour terminer, j'essaie à nouveau de poser une question plus étroite que nous espérons que la communauté regardera plus favorablement.

Quelles sont les décisions de conception spécifiques en Java sont documentées à faire la façon dont ils ne sont pas parce que ce fut la décision de conception préférée, mais plutôt parce qu'il était nécessaire de soutenir la compatibilité ascendante.

Le cas évident est Generics, où vous ne pouvez pas détecter le paramètre de type à l'exécution. (Vous ne pouvez pas faire:

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

Quels sont les autres exemples existent dans la conception du langage et API standard?

Answer 1

Parce que cette question n'a pas une seule bonne réponse, je ne sais pas si ça va mieux que Vol votre autre question.

Trois caractéristiques que je peux penser (en plus d'un effacement générique, que vous avez déjà mentionné) qui a fait des compromis au nom de la compatibilité descendante étaient la nouvelle syntaxe de la boucle, varargs et autoboxing.

La nouvelle syntaxe de la boucle devrait probablement avoir lu for (item in List), mais il aurait fallu faire in en un mot réservé. Cela fait de nombreux problèmes de compatibilité ascendante, et non la moindre, étant le fait que System.in devrait être renommé.

varargs et autoboxing ajouté à la fois les possibilités d'ambiguïté. Par exemple, si vous passez un tableau d'objets à une méthode qui accepte Object... que cela signifie le tableau doit être transmis que le tableau vararg ou comme un élément du tableau de vararg? Cela devient encore plus compliqué s'il y a des surcharges. Autoboxing a des problèmes d'ambiguïté semblables avec surcharge. La solution à ces deux problèmes était d'en faire une règle lors de la résolution appelle la méthode qu'ils sont d'abord résolus avec les pré-règles 1.5 (ex: pas autoboxing et Object... est traitée comme Object[]). Seulement si l'appel de méthode ne peut pas être résolu avec les règles pré-1.5 sont les nouvelles règles 1.5 considérées.

Answer 2

Il y a beaucoup d'exemples dans la bibliothèque standard

• java.awt.Color a les mêmes constantes avec des noms de majuscules et minuscules
• Toutes les méthodes dépréciées à java.util.Date compte tenu de l'introduction de java.util.Calendar - quel gâchis !!
• java.util.Enumeration encore utilisé où java.util.Iterator pourrait le remplacer
• Les classes Swing qui acceptent vecteurs comme arguments, mais pourraient avoir un soutien a ajouté pour java.util.Collection

Answer 3

Un autre serait toutes les classes et méthodes qui sont déconseillés pour plusieurs versions maintenant, mais juste ne disparaîtra pas. Les plus notables sont les différentes méthodes de discussion, qui sont déconseillés.

Answer 4

rétrocompatibilité et génériques