Java 6 Fuente compatibilidad hacia atrás y SQL

Question

Mi entendimiento es que con el fin de mantener la fuente de compatibilidad, Java no introduce nuevos métodos a las interfaces públicas, como que rompe los clientes existentes que implementan las interfaces. de Java Notas de los estados

  

En general, la política es como sigue,   a excepción de posibles incompatibilidades   enumerado más adelante:

     

  

• versiones de mantenimiento (tales como 1.4.1,   1.4.2) No introducir nuevas características del lenguaje o APIs. Lo harán   mantener fuente-compatibilidad con   entre sí.

  

• comunicados de funcionalidad y mayor   comunicados (por ejemplo, 1.3.0, 1.4.0, 5.0)   mantener hacia arriba, pero no hacia abajo   fuente-compatibilidad.

  

Sin embargo, la java.sql paquetes 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, requiriendo nuevos dos nuevos métodos.
• java.sql.Statement introduce 3 nuevos métodos
• java.sql.PreparedStatement introduce 19 nuevos métodos !
• java.sql.ResultSet introduce 48 nuevos métodos !

¿Sabe cómo y por qué consiguió añadido estos métodos? Se java.sql siendo tratado de manera diferente del resto de la plataforma? ¿Conoce la discusión / JSR alrededor de estas adiciones?

Answer 1

me dio la siguiente respuesta de un desarrollador de 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 introducción de incompatibilidades de origen
3. Administrar el cambio de comportamiento de compatibilidad

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

"Tipos de Compatibilidad: Fuente, binario, y de Comportamiento" y "Compatiblemente evolución BigDecimal"

La adición de métodos de las interfaces es binario compatibles y fuente incompatibles, por lo que no se hace comúnmente. En general, cuanto más ampliamente implementado una interfaz es, menos probable es que añadir métodos a ella. El área de JDBC es una excepción a esta norma y utiliza reglas de actualización más flexibles, pero que no causa problemas reales cuando la gente quiere actualizar a una nueva versión del JDK.

Answer 2

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 continuarán funcionando en una nueva JDK. Sólo cuando se intenta llamar a un nuevo método obtendrá una NoSuchMethodError.

Answer 3

Es probable que asumen que los proveedores de controladores de base de datos que implementan estos métodos se mantienen hasta al día con los nuevos tiempos de ejecución de Java, y que es mejor introducir nuevos métodos útiles y temporalmente romper la compatibilidad.

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

Answer 4

Sol nunca se garantiza la compatibilidad entre versiones fuente, solamente la compatibilidad binaria. El ejemplo más común es que el código fuente que contiene 'afirmar' o 'identificadores de enumeración' no se compilará bajo JDK 1.4 (para afirmar) o 1.5 + (por enumeración), pero los archivos existentes .class seguirá funcionando bajo esas nuevas máquinas virtuales de Java.

Puedes probar a utilizar la bandera -fuente para compilar archivos .java la edad establecido nuevas máquinas virtuales de Java, pero todavía puede tener problemas si usted está confiando en las clases de JVM que han cambiado.