Y a-t-il des exemples spécifiques d'incompatibilités en amont au cours des 13 années d'existence de Java?

Question

Il a été de treize ans entre la première version publique de Java 1.0 (1996) et la version stable actuelle 1.6.0_16 (2009).

Au cours de ces treize années suivantes notable des rejets ont été apportées:

• 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)

Je suis à la recherche pour des exemples spécifiques de l'arrière des incompatibilités au cours de l'histoire de la plate-forme Java.

Question:

• En treize ans d'existence de la plate-forme Java, est-il des exemples de Java en arrière incompatibilité où le code source Java/les fichiers de classe Java ciblage version de Java X ne veut pas compiler/exécuter en vertu de la version Y (Y > X)?

Règles de la maison:

• Veuillez inclure des références et des exemples de code, si possible.
• S'il vous plaît essayez d'être très précis en béton/dans votre réponse.
• Une classe qui est marqué comme @Deprecated ne compte pas comme un arrière d'une incompatibilité.

Answer 1

Remarques sur la compatibilité des différentes versions:

• Java 1.4
• Java 5
• Java 6
• Java 7

Le premier grand hoquet je me souviens a été l'introduction d' assert dans Java 1.4. Il a touché beaucoup de JUnit code.

Answer 2

Tout d'abord, Sun estime que toutes les versions que vous avez mentionné (autres que 1.0, bien sûr) pour être mineur, les rejets, les pas principaux.

Je ne suis pas au courant des exemples d'incompatibilité binaire en ce moment. Cependant, il y a eu quelques exemples de source d'incompatibilité:

• En Java 5, "enum" est devenu un mot réservé; il n'était pas avant. Donc, il y avait les fichiers source utilisés enum comme un indicateur de la compilation en java 1.4 qui ne serait pas compiler en java 5.0. Cependant, vous pouvez compiler avec -source de 1,4 pour contourner ce problème.

• Ajouter des méthodes à une interface peut casser la compatibilité de source. Si vous implémenter une interface, puis essayez de compiler que la mise en œuvre avec un JDK qui ajoute de nouvelles méthodes à l'interface, le fichier source n'auront plus de compiler avec succès, car elle permet de ne pas mettre en œuvre l'ensemble de l'interface de membres. Cela a souvent arrivé avec java.sql.Déclaration et les autres interfaces de jdbc. La compilation des formes de ces "non valide" les implémentations encore de travail, sauf si vous avez fait appel à l'une des méthodes qui n'existe pas; si vous le faites, un MissingMethodException sera levée.

Ces quelques exemples, je me souviens off du haut de ma tête, il y a peut être d'autres.

Answer 3

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

Answer 4

Chaque version de Swing s'est cassé quelque chose pour nous, à partir de 1.3 à 1.6.

JDBC question a déjà été évoquée, mais le code existant travaillé.

De 1.5 à 1.6 il y avait un changement dans le comportement de Socket qui a brisé le Cisco client.

Bien sûr, les nouveaux mots réservés ont été introduites.

Le big one qui, je pense, était vraiment impardonnable sur le Soleil est de la partie a du Système.la fonction getenv(). Elle a travaillé en 1.0, puis a été désapprouvée et changé de jeter une erreur sur toutes les plates-formes sous le plutôt douteuse justification que le Mac n'a pas les variables d'environnement système. Puis le Mac a obtenu les variables d'environnement système, de sorte que dans la version 1.5, il a été undeprecated et les œuvres. Il n'existe pas de justification raisonnable pour le faire. De retour d'un ensemble vide sur un Mac (Swing a beaucoup plus de croix-plate-forme des questions si vous voulez soucient que de la cohérence de la plateforme), ou même sur toutes les plateformes.

Je n'ai jamais d'accord avec eux désactivation de la fonctionnalité, mais de le changer pour lever une erreur est juste une pure modification de rupture que si ils allaient faire, ils devraient ont juste enlevé la méthode entièrement.

Mais, vraiment de 1.0 à 1.1 qu'ils étaient moins préoccupés par l'arrière de compatibilité. Par exemple, ils ont abandonné privées "protégés" en tant que modificateur.

Donc le résultat est que, à chaque changement de version est suffisante pour nécessiter une évaluation, c'est pourquoi vous voyez encore beaucoup de 1.4 questions ici.

Answer 5

Le principal qui est, je pense, l'introduction de nouveaux mots réservés:

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

Tout le code que précédemment utilisé ces valeurs comme des identificateurs ne serait pas compiler sous une version ultérieure.

Une autre question que je me souviens à l'origine des problèmes sur un projet sur lequel je travaillais é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 lorsque nous avons mis à niveau à 1,3 ils semblaient tous avoir disparu.