Le JDK est-il compatible "vers le haut" ou "vers l'arrière"?
Rétrocompatibilité compatibilité binaire (ou décroissance compatibilité) - une capacité des clients construite avec une ancienne version de l'API de bibliothèque à exécuter sur une nouvelle ( wiki ).
Vers le haut compatibilité binaire (ou vers l'avant compatibilité) - une capacité des clients construite avec une nouvelle version de l'API de bibliothèque pour fonctionner sur l'ancienne ( wiki ).
Le document général de Sun sur JDK Incompatibilités dans J2SE 5.0 depuis 1.4.2 (et compatibilité Java SE 6 avec J2SE 5. aussi) décrit la compatibilité du JDK comme suit:
JDK 5.0 est vers le haut compatible binaire avec Java 2 SDK, v1.4.2 à l'exception des incompatibilités répertoriées ci-dessous. signifie que, à l'exception des incompatibilités notées, les fichiers de classe construits avec les compilateurs de la version 1.4.2 s'exécuteront correctement dans JDK 5.0 .
Je suppose que les rédacteurs de documentation ont mélangé termes de compatibilité "ascendante" et "descendante" dans cette phrase. Ils décrivent une compatibilité "descendante", mais appellent cette fonctionnalité une compatibilité "ascendante".
Est-ce une faute de frappe, une erreur ou un terme voulu ici? Le JDK est-il compatible "vers le haut" ou "vers l'arrière"?
Notez que pour que quelque chose soit rétrocompatible, il doit y avoir un homologue qui est rétrocompatible (intentionnellement ou non). Par exemple: les lecteurs DVD sont-ils rétrocompatibles avec les CD ou les CD sont-ils compatibles avec les lecteurs DVD?
Dans ce cas, cela dépend si vous regardez le compilateur (ou le bytecode qu'il génère) ou la machine virtuelle.
Le compilateur n'est pas rétrocompatible car le bytecode généré avec Java5 JDK ne fonctionnera pas dans Java 1.4 jvm (sauf s'il est compilé avec le -target 1.4 drapeau). Mais la JVM est rétrocompatible, car elle peut exécuter des bytecodes plus anciens.
Je suppose donc qu'ils ont choisi de considérer la compatibilité du point de vue de javac (car c'est la partie spécifique au JDK), ce qui signifie que le bytecode généré peut être exécuté dans les futures versions du jvm (qui est plus lié au JRE , mais également inclus dans le JDK).
En bref, nous pouvons dire:
- Les JDK sont (généralement) à compatibilité ascendante.
- Les JRE sont (généralement) rétrocompatibles.
(Et cela sert aussi de leçon qui devrait être apprise il y a longtemps: les personnes qui écrivent les compilateurs ont généralement raison, et nous les gens qui les utilisent mal xD)
Soit dit en passant, n'est-il pas plus logique de coupler en arrière/en avant et en bas/en haut plutôt que de les mélanger?
Extension des réponses pour inclure le plus récent Java…
Compatibilité Java SE 7 et JDK 7
Citations de la page non datée d'Oracle:
La compatibilité est un problème complexe. Ce document traite de trois types d'incompatibilités potentielles liées à une version de la plate-forme Java:
- Source : la compatibilité des sources concerne la traduction de Java code source en fichiers de classe, y compris si le code se compile toujours ou non).
- Binaire : la compatibilité binaire est définie dans la spécification de langage Java Java) comme préservant la possibilité de créer des liens sans erreur.
- Comportemental : la compatibilité comportementale inclut la sémantique du code qui est exécuté au moment de l'exécution.
… et
Incompatibilités entre Java SE 7 et Java SE 6 Java SE 7 est fortement compatible avec les versions précédentes de la plate-forme Java. Presque tous les programmes existants devraient fonctionner sur Java SE 7 sans modification. Cependant , il existe quelques sources potentielles mineures et incompatibilités binaires dans le JRE et le JDK qui impliquent des circonstances rares et des "cas de coin" qui sont documentés ici pour être complets.
Incompatibilités Java SE 7 dans le langage, la JVM ou Java SE
… et
Incompatibilités entre JDK 7 et JDK 6
Incompatibilités JDK 7 dans javac, dans HotSpot ou Java API SE
(Pas de préambule - juste une liste d'incompatibilités.)
Vers l'arrière uniquement. La compatibilité ascendante ("accepter gracieusement les entrées destinées aux versions ultérieures de lui-même") nécessiterait que la JVM 1.5 soit capable d'exécuter du code compilé 1.6, ce qu'elle ne peut pas.
Rétrogradation requiert "si cela peut fonctionner avec des entrées générées par un périphérique plus ancien", ce qui est vrai car une JVM 1.6 peut exécuter du code compilé 1.5.
Chaque version du JDK/JRE coïncide avec une version de Java bytecode. Chaque compilateur produit le code d'une version de bytecode spécifique. Chaque JVM comprend une version et toutes les versions antérieures d'une version de bytecode spécifique.
Lorsque la JVM charge une classe, elle vérifie la version du bytecode et si elle est> à la dernière version comprise de la JVM, vous obtiendrez une erreur. (ClassVersionError ou quelque chose).
Java (VM) est rétrocompatible. Code construit par Java 1.4.2 fonctionnera sur les machines virtuelles 1.5 et 6. Le compilateur JDK n'est pas rétrocompatible. Le code ne peut donc pas être compilé par Java 1.5 to exécuter sur 1.4.2 par exemple.
JDK est rétrocompatible, c'est-à-dire que le code d'octet conforme à la spécification 1.4.2 fonctionnera sur Java 5 JVM
JDK est compatible vers le bas selon la définition du wiki.
Il devrait être rétrocompatible.