telecharger - télécharger java 64 bits




Existe-t-il des exemples spécifiques d'incompatibilités avec les versions antérieures entre les versions de Java? (10)

Chaque sortie de Swing a cassé quelque chose pour nous, de 1.3 à 1.6.

Le problème JDBC a déjà été mentionné, mais le code existant a fonctionné.

De 1,5 à 1,6, le comportement de Socket a changé, ce qui a entraîné une rupture du client Cisco.

Bien sûr, de nouveaux mots-clés réservés ont été introduits.

Le plus gros qui, à mon avis, était vraiment impardonnable était celui de System.getenv (). Cela fonctionnait dans la version 1.0, puis était obsolète et modifié pour générer une erreur sur toutes les plates-formes sous la justification plutôt douteuse que le Mac n'avait pas de variables d'environnement système. Ensuite, le Mac a obtenu les variables d’environnement du système, donc dans la version 1.5, il n’était pas obsolète et fonctionne. Il n'y a aucune justification raisonnable pour cela. Renvoyez un jeu vide sur un Mac (Swing pose des problèmes beaucoup plus importants entre plates-formes si vous souhaitez vous soucier de ce niveau de cohérence multiplate-forme) ou même sur toutes les plates-formes.

Je n'ai jamais accepté qu'ils désactivent la fonctionnalité, mais la modifier pour créer une erreur était simplement un changement radical qui, s'ils l'avaient fait, ils auraient simplement dû supprimer complètement la méthode.

Mais, de 1,0 à 1,1, ils étaient moins préoccupés par la compatibilité avec les versions antérieures. Par exemple, ils ont supprimé "private protected" en tant que modificateur.

Le résultat est que chaque version change suffisamment pour nécessiter une évaluation approfondie, c’est pourquoi vous voyez toujours beaucoup de questions 1.4 ici sur les SO.

Existe-t-il des incompatibilités entre les versions Java où les fichiers de code source / Java ciblant la version X de Java ne sont pas compilés / exécutés sous la version Y (où Y> X)?

Par "version Java", j'entends des versions telles que:

  • JDK 1.0 (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 si possible.
  • S'il vous plaît essayez d'être très spécifique / concret dans votre réponse.
  • Une classe marquée comme @Deprecated ne compte pas comme une incompatibilité en arrière.

Comme Sean Reilly l'a dit, une nouvelle méthode peut casser votre code. En plus du cas simple où vous devez implémenter une nouvelle méthode (cela produira un avertissement du compilateur), il existe un cas pire: une nouvelle méthode dans l'interface a la même signature qu'une méthode que vous avez déjà dans votre classe. Le seul indice du compilateur est un avertissement indiquant que l'annotation @Override est manquante (Java 5 pour les classes, l'annotation est prise en charge pour les interfaces dans Java 6 mais facultative).


Encore un autre exemple de compatibilité de java.sql:

En 1.5, une méthode compareTo (Date) a été ajoutée à java.sql.Timestamp. Cette méthode lève une exception ClassCastException si la date fournie n'est pas une instance de java.sql.Timestamp. Bien sûr, java.sql.Timestamp étend Date et Date avait déjà une méthode compareTo (Date) qui fonctionnait avec toutes les dates. Cela signifiait donc que le code qui comparait un horodatage à une date (autre que l'horodatage) était interrompu à l'exécution .

Il est intéressant de noter qu'il semble que 1.6 semble avoir résolu ce problème. Alors que la documentation de java.sql.Timestamp.compareTo (Date) indique toujours "Si l'argument n'est pas un objet Timestamp , cette méthode lève un objet ClassCastException ", l'implémentation réelle dit le contraire. Mon hypothèse est qu'il s'agit d'un bogue de documentation.


Entre 1.3 et 1.4, l'interprétation de Long.parseLong (String) traitait la chaîne vide différemment. 1.3 renvoie une valeur 0 , tandis que 1.4 lève une NumberFormatException .

Les recompilations ne sont pas nécessaires, mais le code de travail cessait de fonctionner s'il reposait sur le comportement de la version 1.3.


Je ne l'ai pas essayé, mais en théorie, cela fonctionnerait en Java 1.1 et en Java 1.2. (Plus d' infos ici )

public class Test {
    float strictfp = 3.1415f;
}

L'interface java.sql.Connection été étendue de Java 1.5 à Java 1.6, rendant java.sql.Connection compilation de toutes les classes ayant implémenté cette interface.


Le principal auquel je puisse penser est l’introduction de nouveaux mots réservés:

Java 1.3: strictfp
Java 1.4: assert
Java 5.0: enum

Tout code ayant précédemment utilisé ces valeurs comme identificateurs ne serait pas compilé sous une version ultérieure.

Un autre problème dont je me souviens, ayant posé des problèmes sur un projet sur lequel j'ai travaillé, était qu'il y avait un changement dans la visibilité par défaut de JInternalFrames entre 1.2 et 1.3 . Ils étaient visibles par défaut, mais lors de la mise à niveau vers la version 1.3, ils semblaient tous avoir disparu.


Les éléments suivants seront compilés sous Java 1.4 mais pas Java 1.5 ou version ultérieure.

(Java 5 a introduit le mot clé "enum". Remarque: il sera compilé dans Java 5 si l'option "-source 1.4" est fournie.)

public class Example {
    public static void main(String[] args) {
        String enum = "hello";
    }
}

Tout d’abord, Sun considère que toutes les versions que vous avez mentionnées (à l’exception de la version 1.0 bien sûr) sont des versions mineures et non majeures.

Je ne connais aucun exemple d'incompatibilité binaire à cette époque. Cependant, il y a eu quelques exemples d'incompatibilité de source:

  • En Java 5, "enum" est devenu un mot réservé; ce n'était pas avant. Par conséquent, certains fichiers sources utilisaient enum comme identifiant pour la compilation dans Java 1.4 et non dans Java 5.0. Cependant, vous pouvez compiler avec -source 1.4 pour contourner ce problème.

  • L'ajout de méthodes à une interface peut également empêcher la compatibilité de la source. Si vous implémentez une interface, puis essayez de la compiler avec un JDK qui ajoute de nouvelles méthodes à l'interface, le fichier source ne sera plus compilé correctement car il n'implémentera pas tous les membres de l'interface. Cela est souvent arrivé avec java.sql.Statement et les autres interfaces jdbc. Les formes compilées de ces implémentations "non valides" fonctionneront toujours, sauf si vous appelez réellement l'une des méthodes qui n'existent pas; Si vous faites cela, une exception MissingMethodException sera levée.

Ce sont quelques exemples que je peux rappeler de mémoire, il y en a peut-être d'autres.






backwards-compatibility