Un scénario hypothétique:
J'ai un projet dont le niveau de conformité de la source est spécifié à 1,5. Maintenant, je compile ce projet avec deux JDK différents: au début avec JDK 6 Update 7, puis avec JDK 6 Update 20.
Ces deux Deux JDKS produisent-ils différents code d'octet Java, bien qu'ils ne diffèrent que dans leur version de mise à jour?
8 Réponses :
Le code généré ne diffère généralement que dans le cas de corrections de bugs compilateur.
Cependant, les JLS ne sont pas non spécifient un mappage 1: 1 de code source au code d'octet généré, vous ne devez donc pas compter sur le même code d'octet à générer exactement.
Pourquoi sur Terre voudrait-elle avoir la peine d'émettre une mise à jour d'un kit de développement s'il n'a pas conduit à modifier le code d'octet dans au moins certains cas? Je doute fermement que quiconque le ferait juste pour les mises à jour de la documentation.
Pour répondre à votre question rhétorique: comme l'interprétation / l'exécution du code octet ainsi que les bibliothèques ont peut-être changé. la plupart des modifications à la JDK entre les mises à jour sont à l'exécution et à la bibliothèque et pas au compilateur.
Il n'y a rien qui empêcherait les différentes versions de générer des bytecodes différents, tant qu'il est conforme au comportement spécifié dans les JLS. Les JLS laisse de nombreux détails de la mise en œuvre pour varier d'une implémentation à l'autre.
Répondons de l'autre côté: rien ne garantit que deux versions de la JDK produisent le code d'octet identique. Vous pouvez donc vous attendre à des différences en général.
Le bytecode pourrait légèrement différer, mais ce n'est rien à craindre car il sera toujours compatible.
Ce qui sera vraiment exécuté dépend de JIT.
Comme généralement, c'est pour différents compilateurs, il est également dans le cas Java: le résultat doit être identique, mais la façon dont il est atteint peut être (du point de vue des bytecodes) différent., par exemple. à cause des optimisations ou de la même manière. La JVM est une machine à base de pile; Ce qui suit est un exemple imaginaire (je ne connais pas JVM Mnemonics pour les instructions OPCODES)
push 19 push 1 add push 10 add
Le compilateur de par exemple JDK 6 Mise à jour 7 peut produire un bytecode légèrement différent que le compilateur de JDK 6 Mise à jour 20, mais comme il est à la fois Java 6, les fichiers de classe seront entièrement compatibles - vous pourrez exécuter le code compatible avec Mise à jour 20 sur la mise à jour 7 sans aucun problème.
entre les principales versions Java (par exemple, Java 5 vs. Java 6) Il peut être possible de modifier ce code compilé sur la version plus récente ne s'exécutera pas sur la version plus ancienne. Par exemple, pour Java 7, il y aura probablement une nouvelle instruction, invokedynamic . Les fichiers de classe contenant cette instruction ne seront pas exécuts sur les versions Java plus anciennes.
Ces gros changements ne sont toutefois jamais faits entre les versions de mise à jour.
Si vous compilez avec différentes versions JDK, je conseillerais d'utiliser l'option cible à Javac.
Sinon, vous ne pourrez peut-être pas courir le pot avec un ancien JDK.
Vous pouvez également utiliser l'option source à Javac, afin de vous assurer que le développeur n'utilise pas de classes / méthodes ajoutées dans un JDK plus récent.
J'y ai pensé quand j'avais des problèmes avec un déploiement chaud sur mon JBoss (voir Stackoverflow.com/Questtions/3005919/... ).
@PolyGenLubricants: La compatibilité binaire concerne les modifications de code source autorisées tout en conservant les fichiers de classe compatibles avec d'autres fichiers de classe qui ne sont pas recompilés. C'est un sujet utile mais ne pense pas que cela s'applique à ce problème.