Compatibilidad con versiones anteriores de Java 6 Source y SQL

Question

Tengo entendido que para mantener la compatibilidad de fuentes, Java nunca introduce nuevos métodos a las interfaces públicas, ya que eso rompe los clientes existentes que implementan las interfaces. Java Release notes estados

En general, la política es el siguiente, excepto por posibles incompatibilidades enumeradas más adelante:

• versiones de mantenimiento (tales como 1.4.1, 1.4.2 ) no lo hacen introducir cualquier nueva característica de idioma o API. Contendrán compatibilidad de origen con entre sí.

• comunicados de funcionalidad y principales comunicados (como 1.3.0, 1.4.0, 5.0) mantienen hacia arriba, pero no hacia abajo fuente-compatibilidad.

Sin embargo, los paquetes java.sql y javax.sql siguen evolucionando e introducir muchos cambios incompatibles. Por ejemplo, he notado los siguientes cambios incompatibles (introducidas en Java 6):

• java.sql.Statement extiende java.sql.Wrapper, lo que requiere nuevos dos nuevos métodos.
• java.sql.Statement presenta 3 nuevos métodos
• java.sql.PreparedStatement presenta 19 métodos nuevos!
• java.sql.ResultSet presenta 48 nuevos métodos!

¿Sabes cómo y por qué se agregaron estos métodos? ¿Se trata java.sql de manera diferente al resto de la plataforma? ¿Conoces la discusión/JSR sobre estas adiciones?

Answer 1

Me dio la siguiente respuesta de un desarrollador Sun

La política de la evolución general de las API en el JDK para versiones de funciones como JDK 7 es

1. No rompa la compatibilidad binaria (como se define en el capítulo JLSv3 13)
2. Evitar la fuente de introducción de incompatibilidades
3. gestionar el cambio de comportamiento de compatibilidad

(Para más, mucho más de lo que le gustaría leer en diferentes tipos de compatibilidad ver

"Kinds of Compatibility: Source, Binary, and Behavioral" y "Compatibly Evolving BigDecimal"

Adición de métodos de las interfaces es binario compatible pero fuente incompatibles , por lo que no se hace comúnmente. En general, cuanto más ampliamente implementada es una interfaz, es menos probable que agreguemos métodos. El área de JDBC es una excepción a esta política y usa reglas de actualización más flexibles, pero eso causa problemas reales cuando las personas desean actualizar a una nueva versión de JDK.

Answer 2

Probablemente asumen que los proveedores de controladores de bases de datos que implementan esos métodos se mantienen actualizados con los nuevos tiempos de ejecución de Java, y que es mejor introducir nuevos métodos útiles y romper temporalmente la compatibilidad.

Por supuesto, que podría haber diseñado mejor manera que romper la compatibilidad no sería necesario ...

Answer 3

Tenga en cuenta que la adición de nuevos métodos sólo rompen la compatibilidad fuente, las implementaciones ya compilados de Statement o ResultSet en un controlador JDBC se continuar corriendo en un JDK más nuevo. Solo cuando intentes llamar a un nuevo método obtendrás un NoSuchMethodError.

Answer 4

Sun nunca garantiza la compatibilidad de origen entre versiones, solo compatibilidad binaria. El ejemplo más común es que el código fuente que contiene los identificadores 'assert' o 'enum' no se compilará bajo JDK 1.4 (para assert) o 1.5+ (para enum), pero los archivos .class existentes seguirán ejecutándose bajo esas JVM más recientes.

Puede intentar usar el indicador de fuente para compilar archivos .java más antiguos bajo las JVM más nuevas, pero aún puede tener problemas si confía en las clases de jvm que han cambiado.