Java 6 Source compatibilidad hacia atrás y SQL

Según entiendo, para mantener la compatibilidad de las fonts, Java nunca introduce nuevos methods para las interfaces públicas, ya que eso rompe los clientes existentes que implementan las interfaces. Estados de notas de la versión de Java

En general, la política es la siguiente, a exception de cualquier incompatibilidad que se detalla a continuación:

  • Las versiones de mantenimiento (como 1.4.1, 1.4.2) no introducen ninguna característica de idioma o API nuevas. Mantendrán la compatibilidad de fuente entre ellos.

  • Los lanzamientos de funcionalidad y versiones principales (como 1.3.0, 1.4.0, 5.0) mantienen hacia arriba pero no hacia abajo la compatibilidad de fonts.

Sin embargo, los packages java.sql y javax.sql continúan evolucionando e introducen muchos cambios incompatibles. Por ejemplo, noté los siguientes cambios incompatibles (introducidos en Java 6):

  • java.sql.Statement extiende java.sql.Wrapper , requiriendo dos nuevos methods nuevos.
  • java.sql.Statement presenta 3 nuevos methods
  • java.sql.PrepanetworkingStatement presenta 19 nuevos methods!
  • java.sql.ResultSet presenta 48 nuevos methods!

¿Sabes cómo y por qué se agregaron estos methods? ¿Se está tratando java.sql forma diferente al rest de la plataforma? ¿Conoces la discusión / JSR sobre estas adiciones?

Recibí la siguiente respuesta de un desarrollador de Sun

La política de evolución general para las API en el JDK para lanzamientos de características como JDK 7 es

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

(Para más, mucho más de lo que le gustaría leer sobre diferentes types de compatibilidad, vea

"Tipos de compatibilidad: fuente, binary y comportamental" y "compatible en evolución BigDecimal"

La adición de methods a las interfaces es compatible con binarys pero la fuente no es compatible, por lo que no se realiza comúnmente. En general, cuanto más ampliamente implementada es una interfaz, es less probable que agreguemos methods. El área de JDBC es una exception 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.

Tenga en count que al agregar nuevos methods solo se rompe la compatibilidad con el origen, las implementaciones ya comstackdas de Statement o ResultSet en un controller JDBC continuarán ejecutándose en un JDK más nuevo. Solo cuando intentes llamar a un nuevo método obtendrás un NoSuchMethodError .

Probablemente asumen que los proveedores de controlleres de database que implementan esos methods se mantienen actualizados con los nuevos times de ejecución de Java, y que es mejor introducir nuevos methods útiles y romper temporalmente la compatibilidad.

Por supuesto, podrían haberlo diseñado mejor para que no sea necesario romper la compatibilidad …

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

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

Intereting Posts