Java 6 Source rétrocompatibilité et SQL

Question

Si je comprends bien que pour maintenir la compatibilité source, Java présente jamais de nouvelles méthodes pour les interfaces publiques, qui brise les clients existants mettant en œuvre les interfaces. Java Release Notes états

  

En général, la politique est la suivante,   à l'exception d'éventuelles incompatibilités   énumérés ci-après:

     

  

• Les versions de maintenance (par exemple 1.4.1,   1.4.2) ne créent pas de nouvelles fonctionnalités linguistiques ou API. Elles vont   maintenir source de compatibilité avec   les uns des autres.

  

• Communiqués de fonctionnalité et les principaux   les rejets (comme 1.3.0, 1.4.0, 5.0)   maintenir vers le haut mais pas vers le bas   source de compatibilité.

  

Et pourtant, les paquets java.sql et javax.sql continuent d'évoluer et d'introduire de nombreux changements incompatibles. Par exemple, j'ai remarqué les changements incompatibles suivants (introduites en Java 6):

• java.sql.Statement étend java.sql.Wrapper, nécessitant deux nouvelles méthodes nouvelles.
• java.sql.Statement 3 nouvelles méthodes introduit
• java.sql.PreparedStatement 19 introduit de nouvelles méthodes
• java.sql.ResultSet 48 introduit de nouvelles méthodes

Savez-vous comment et pourquoi ces méthodes avez été ajouté? Est-java.sql traité différemment du reste de la plate-forme? Connaissez-vous la discussion / JSR autour de ces ajouts?

Answer 1

J'obtenu la réponse suivante à partir d'un développeur Sun

La politique d'évolution générale des API dans le JDK pour les longs comme les versions 7 est JDK

1. Ne pas casser la compatibilité binaire (tel que défini au chapitre JLSv3 13)
2. éviter d'introduire des incompatibilités source
3. Gérer le changement de comportement compatibilité

(Pour en savoir plus, beaucoup plus que vous voulez lire sur les différents types de voir la compatibilité

"Types de compatibilité: Source, binaire, et du comportement" et "Compatiblement Evolving BigDecimal"

Ajout de méthodes aux interfaces est binaire compatible et source incompatible, il est donc généralement pas fait. En général, plus une interface est largement mis en œuvre, moins il est probable que nous voulons ajouter des méthodes à lui. La zone JDBC est une exception à cette politique et utilise des règles plus souples de mise à niveau, mais cela provoque des vrais problèmes quand les gens veulent passer à une nouvelle version JDK.

Answer 2

Notez que l'ajout de nouvelles méthodes rompent seulement la compatibilité des sources, les implémentations déjà compilées de Statement ou ResultSet dans un pilote JDBC continueront de fonctionner sur une nouvelle JDK. Seulement lorsque vous essayez d'appeler une nouvelle méthode, vous obtiendrez un NoSuchMethodError.

Answer 3

Ils supposent probablement que les vendeurs de pilote de base de données qui mettent en œuvre ces méthodes à suivre à jour avec de nouveaux runtimes Java, et qu'il est préférable d'introduire des méthodes nouvelles et utiles briser temporairement la compatibilité.

Bien sûr, ils auraient pu conçus mieux pour que la compatibilité de rupture ne serait pas nécessaire ...

Answer 4

Sun ne garantit jamais la compatibilité source entre les versions, seule la compatibilité binaire. L'exemple le plus courant est que le code source qui contient « assert » ou « ENUM » identificateurs ne compilera pas du JDK 1.4 (pour assert) ou 1.5+ (pour ENUM), mais les fichiers existants continuera à fonctionner dans ces nouveaux JVMs.

Vous pouvez essayer d'utiliser le drapeau -source pour compiler des fichiers .java anciens sous nouveaux JVMs mais vous pouvez encore rencontrer des problèmes si vous comptez sur les classes jvm qui ont changé.