Ma compréhension est que, afin de maintenir la compatibilité de la source, Java n'entraîne jamais de nouvelles méthodes aux interfaces publiques, car cela enfreint les clients existants implémentant les interfaces. Notes de version Java états
En général, la politique est la suivante, Sauf pour toute incompatibilité énumérés plus loin:
Communiqués de maintenance (tels que 1.4.1, 1.4.2) Ne pas introduire de nouvelles fonctionnalités ou API linguistiques. Elles vont maintenir la compatibilité source avec l'autre.
Communiqués de fonctionnalité et majeur Communiqués (tels que 1.3.0, 1.4.0, 5.0) maintenir vers le haut mais pas vers le bas Compatibilité source.
Cependant, les paquets
java.sql etjavax.sql continuent à évoluer et à introduire de nombreuses modifications incompatibles. Par exemple, j'ai remarqué les modifications incompatibles suivantes (introduites dans Java 6):
java.sql.statement < / code>étendjava.sql.wrapper , nécessitant de nouvelles nouvelles méthodes.java.sql.statement < / code>introduit 3 nouvelles méthodesjava.sql.preparedStatement < / code>introduit 19 nouvelles méthodes!Java.SQL.RESULTset < / code>introduit 48 nouvelles méthodes!Savez-vous comment et pourquoi ces méthodes ont été ajoutées? Est
java.sql étant traité différemment du reste de la plate-forme? Connaissez-vous la discussion / JSR autour de ces ajouts?
4 Réponses :
Ils supposent probablement que les fournisseurs de pilotes de base de données qui mettent en œuvre ces méthodes se maintiennent à jour avec les nouveaux roulements Java et qu'il est préférable d'introduire de nouvelles méthodes utiles et de rompre temporairement la compatibilité.
Bien sûr, ils auraient pu mieux l'avoir conçu pour que la compatibilité de la rupture ne soit nécessaire ...
Notez que l'ajout de nouvelles méthodes ne casse que la compatibilité des sources, des implémentations déjà compilées de instruction ou Result dans un pilote JDBC continuera à fonctionner sur un nouveau JDK. Seulement lorsque vous essayez d'appeler une nouvelle méthode, vous obtiendrez un Noschmethoderror .
Correct. C'est pourquoi j'ai limité la question à la compatibilité de la source!
Ce n'est pas correct. Il brise tous les pilotes mis en œuvre pour Java 5. Consultez ma question Stackoverflow.com/Questtions/1238252/...
@Zhang Le problème dans la question référencée concerne la compatibilité binaire à la baisse; I.e .. Utilisez Java 6 JDK tout en ciblant Java 5 JDK. Java n'a jamais promis que ça!
Sun ne garantit jamais la compatibilité source entre les versions, seule la compatibilité binaire. L'exemple le plus courant est que le code source contenant des identificateurs «Assert» ou «Enum» ne compilera pas sous JDK 1.4 (pour ASSERT) ou 1,5+ (pour ENUM), mais les fichiers .Class existants seront toujours exécutés sous ces nouveaux JVMS. < / p>
Vous pouvez essayer d'utiliser le drapeau -Source pour compiler des fichiers plus anciens .java sous New JVMS, mais vous pouvez toujours rencontrer des problèmes si vous comptez sur des classes JVM qui ont changé.
Pas tout à fait vrai. J'ai joint la politique de compatibilité source dans la question. Ils sont plus indulgent avec la compatibilité des sources de rupture que la compatibilité binaire; Mais ils documentent généralement ces changements. Java.SQL Les modifications ne sont pas documentées dans les notes de version.
J'ai eu la réponse suivante d'un développeur Sun
La politique générale de l'évolution des API dans la JDK pour les communiqués de fonctionnalités telles que JDK 7 est
(Pour plus, beaucoup plus que vous ne souhaitez lire sur différents types de compatibilité, voir
"" Types de compatibilité: source, binaire et comportementale " et "Evolution compatible BigDecimal"
Ajout de méthodes aux interfaces est binaire compatible mais source incompatible, donc il n'est donc pas couramment fait. En règle générale, plus une interface est largement implémentée, les moins susceptibles de les ajouter à des méthodes. La région JDBC est une exception à la présente politique et utilise des règles de mise à niveau de lâche, mais cela cause de véritables problèmes lorsque les gens veulent passer à une nouvelle version JDK.
Devrait-il être " pas causer de vrais problèmes"?
L'ajout de méthodes ne casse pas la compatibilité vers le haut, ce n'est que vers le bas (qui est autorisé pour les rejets majeurs, comme Java 6).
Mais les types
java.sql sont des interfaces, pas des classes.