Y a-t-il des exemples précis d'incompatibilités entre les versions Java arrière?
https://stackoverflow.com/questions/1654923
-
11-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Y at-il eu des incompatibilités entre Java versions où le code source Java / Java fichiers de classe Java ciblant la version X ne sera pas compiler / exécuter sous la version Y (où Y> X)?
Par "version Java" Je veux dire des versions telles que:
- 1.0 JDK (Janvier 1996)
- JDK 1.1 (Février 1997)
- J2SE 1.2 (Décembre 1998)
- J2SE 1.3 (mai 2000)
- J2SE 1.4 (Février 2002)
- J2SE 5.0 (Septembre 2004)
- Java SE 6 (Décembre 2006)
Règles de la maison:
- S'il vous plaît inclure des références et des exemples de code lorsque cela est possible.
- S'il vous plaît essayer d'être très précis / concret dans votre réponse.
- Une classe qui est marqué comme @deprecated ne compte pas comme une incompatibilité arrière.
Autres conseils
Tout d'abord, Sun considère en fait tous les communiqués que vous avez mentionné (autres que 1.0 bien sûr) être mineur de presse, pas importants.
Je ne connais aucun exemple d'incompatibilité binaire en ce moment-là. Cependant, il y a eu quelques exemples d'incompatibilité de source:
-
En Java 5, "ENUM" est devenu un mot réservé; il n'a pas été auparavant. Par conséquent, il les fichiers source sont utilisés que ENUM comme un identifiant qui compilerait en Java 1.4 qui ne compilera pas en Java 5.0. Cependant, vous pouvez compiler avec -source 1.4 pour contourner cela.
-
Ajout des méthodes à une interface peut briser la compatibilité des sources aussi bien. Si vous implémentez une interface, et essayez ensuite de compiler que la mise en œuvre avec un JDK qui ajoute de nouvelles méthodes à l'interface, le fichier source ne sera plus compilé avec succès, car il ne met pas en œuvre tous les membres de l'interface. Cela a souvent passé avec java.sql.Statement et les autres interfaces JDBC. Les formes compilées de ces mises en œuvre « invalides » continueront de fonctionner à moins que vous appelez en fait l'une des méthodes qui n'existe pas; si vous faites cela, une MissingMethodException sera levée.
Voici quelques exemples que je peux rappeler hors du haut de ma tête, il peut y avoir d'autres.
Le java.sql.Connection d'interface a été prolongée à partir de Java 1.5 à Java 1.6 faire la compilation de toutes les classes qui ont mis en échec cette interface.
Chaque version Swing a cassé quelque chose pour nous, de 1.3 à 1.6.
La question JDBC a déjà été mentionné, mais le code existant travaillé.
De 1,5 à 1,6 il y avait un changement dans le comportement du socket qui a brisé le client Cisco.
Bien sûr de nouveaux mots-clés réservés ont été introduits.
Le grand que je pense impardonnable était vraiment de la part de Sun était System.getenv (). Il a travaillé à 1,0, puis a été dépréciée et a changé de jeter une erreur sur toutes les plates-formes sous la justification plutôt douteuse que le Mac n'avait pas des variables d'environnement système. Ensuite, le Mac a des variables d'environnement du système, donc en 1.5 il a été undeprecated et travaille. Il n'y a pas de justification raisonnable pour le faire. Retour un ensemble vide sur un Mac (Swing a beaucoup plus gros problèmes multiplateformes si vous voulez prendre soin de ce niveau de cohérence multi-plateforme) ou même sur toutes les plateformes.
Je ne ai jamais d'accord avec les désactiver la fonction, mais de le changer pour lancer une erreur était juste un pur changement de rupture que s'ils allaient le faire, ils auraient dû simplement supprimer la méthode entièrement.
Mais, vraiment 1,0 à 1,1, ils étaient moins préoccupés par compatibilité ascendante. Par exemple, ils ont abandonné « privé protégé » comme modificateur.
Ainsi, le résultat est que chaque version change assez pour nécessiter une évaluation proche, c'est la raison pour laquelle vous voyez encore beaucoup de questions 1.4 ici sur le SO.
La principale que je peux penser est l'introduction de nouveaux mots réservés:
Java 1.3: strictfp
Java 1.4: assert
Java 5.0: enum
Tout code utilisé précédemment ces valeurs que les identificateurs ne compilerait pas dans une version ultérieure.
Une autre question que je me souviens causer des problèmes sur un projet que j'ai travaillé était qu'il y avait un changement de la visibilité par défaut de JInternalFrames entre 1,2 et 1,3 . Ils étaient visibles par défaut, mais quand nous sommes passés à 1,3, ils semblaient tous avoir disparu.
Entre 1,3 et 1,4 sur l'interprétation de Long.parseLong (String) traitées différemment la chaîne vide. 1.3 renvoie une valeur de 0, alors que 1,4 jette un NumberFormatException.
recompile ne sont pas nécessaires, mais le code de travail a cessé de fonctionner si elle reposait sur le comportement 1.3.
Ce qui suit la compilation sous Java 1.4, mais pas Java 1.5 ou version ultérieure.
(Java 5 introduit 'ENUM' comme mot clé. Remarque: il compilera en Java 5 si l'option "-source 1.4" est fourni.)
public class Example {
public static void main(String[] args) {
String enum = "hello";
}
}
Il est évident que la convention de nommage des libérer les noms est pas rétrocompatible.
- 1.0 JDK (23 Janvier, 1996)
- JDK 1.1 (19 Février, 1997)
- J2SE 1.2 (8 Décembre, 1998)
- J2SE 1.3 (le 8 mai 2000)
- J2SE 1.4 (6 Février, 2002),
- J2SE 5.0 (30 Septembre, 2004),
- Java SE 6 (11 Décembre, 2006)
- Java SE 6 Update 10, mise à jour 12, mise à jour 14, mise à jour 16
- Java SE 7 ??? JDK7?
Encore un autre exemple de la compatibilité de la rupture java.sql:
Dans la version 1.5 une méthode compareTo (date) a été ajouté à java.sql.Timestamp. Cette méthode jeter un ClassCastException si la date fournie n'était pas une instance de java.sql.Timestamp. Bien sûr, java.sql.Timestamp étend et Date avait déjà une méthode compareTo (date) qui a travaillé avec toutes les dates, donc cela signifie que le code qui a comparé un Horodatage à un (non Timestamp) Date casserait lors de l'exécution dans 1,5 .
Il est intéressant de noter qu'il semble que 1.6 semble avoir résolu ce problème. Bien que la documentation java.sql.Timestamp.compareTo (date) dit encore: « Si l'argument n'est pas un objet Timestamp, cette méthode renvoie un objet ClassCastException », la mise en œuvre effective dit le contraire. Je pense que ceci est un bogue de documentation.
Voir le rapport sur les modifications de l'API pour la bibliothèque de classes JRE ici: http: // abi-laboratory.pro/java/tracker/timeline/jre/
Le rapport comprend une analyse en arrière binary- et source de compatibilité des classes Java.
Le rapport est généré par le japi-conformité vérificateur outil.
...
Une autre analyse intéressante pour JDK 1,0-1,6 vous pouvez trouver japitools JDK la page de -Résultats.
Comme Sean Reilly dit, une nouvelle méthode peut briser votre code. Outre le cas simple que vous devez mettre en œuvre une nouvelle méthode (ce qui produira un avertissement du compilateur) il y a le pire des cas: une nouvelle méthode dans l'interface a la même signature en tant que méthode que vous faites déjà avoir Dans votre classe. Le seul indice du compilateur est un avertissement que l'annotation @Override manque (Java 5 pour les classes, l'annotation est prise en charge pour les interfaces en Java 6, mais en option).
Je ne l'ai pas essayé, mais en théorie, cela travaillerais en Java 1.1 et Java 1.2 en briser. (Plus infos ici )
public class Test {
float strictfp = 3.1415f;
}
De son expérience personnelle, nous avons eu quelques AWT / Swing champs de texte intégrés dans un cadre de SWT_AWT à 1,5, qui ont cessé d'être modifiable après la mise à niveau 1.6.
