¿Qué diseños de Java se realizan de forma explícita para apoyar la compatibilidad hacia atrás? [cerrado]

Question

Desde esta pregunta es de nuevo a cuatro votos a cerrar, estoy tratando de nuevo para hacer una pregunta más estrecho que esperemos que la comunidad va a ver de manera más favorable.

¿Qué decisiones de diseño específicas de Java se documentan que ser hecho de la manera que ellos no son porque esa era la decisión de diseño preferido, sino más bien porque era necesario para apoyar la compatibilidad hacia atrás.

El caso es obvio genéricos, donde no se puede detectar el parámetro de tipo en tiempo de ejecución. (Por lo que no puede hacer:

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

Lo que existen otros ejemplos de este tipo en el diseño de lenguajes y API estándar?

Answer 1

Debido a esta pregunta no tiene una única respuesta correcta, no estoy seguro de si va a ir mejor que su otra pregunta.

Hay tres características que se me ocurre (además de borrado genérica, que ya lo ha dicho) que hizo compromisos en nombre de la compatibilidad con versiones anteriores eran la nueva sintaxis para el bucle, varargs y autoboxing.

La nueva sintaxis para el bucle probablemente debería haber leído for (item in List), pero eso habría requerido hacer in en una palabra reservada. Esto sería causado numerosos problemas de compatibilidad hacia atrás, no menos importante de los cuales es el hecho de que System.in tendría que ser cambiado de nombre.

varargs y autoboxing tanto añadió las posibilidades de ambigüedad. Por ejemplo, si se pasa una matriz de objetos a un método que acepta Object... ¿significa que la matriz debe ser pasado como la matriz vararg o como un elemento de la matriz vararg? Esto se complica aún más si hay sobrecargas. Autoboxing tiene problemas de ambigüedad similares con sobrecarga. La solución a ambos problemas era hacer una regla que cuando la solución de llamadas de método que se resuelven en primer lugar con las reglas pre-1,5 (es decir: no autoboxing, y Object... se trata como Object[]). Sólo si la llamada al método no se puede resolver con las reglas anteriores a la 1.5 son las nuevas reglas consideradas 1,5.

Answer 2

Hay muchos ejemplos en la biblioteca estándar

• java.awt.Color tiene las mismas constantes con nombres mayúsculas y minúsculas
• Todos los métodos obsoletos en java.util.Date dada la introducción de java.util.Calendar - lo que es un desastre !!
• java.util.Enumeration sigue siendo utilizado en java.util.Iterator podría reemplazarlo
• Trabajo en oscilación que aceptan vectores como argumentos, pero podría haber tenido el apoyo añadido para java.util.Collection

Answer 3

Otra sería todas las clases y métodos que se han dejado de múltiples versiones por ahora, pero simplemente no va a desaparecer. Los más notables son los diversos métodos de rosca, que están en desuso.

Answer 4

compatibilidad hacia atrás y genéricos