JDK est-il compatible "vers le haut" ou "en arrière"?

Question

En arrière la compatibilité binaire (ou à la baisse de compatibilité) - une capacité de clients construit avec une vieille version de bibliothèque d'API pour s'exécuter sur un nouveau (wiki).

La hausse de la compatibilité binaire (ou de l'avant de compatibilité) - une capacité de clients construit avec une nouvelle version de bibliothèque d'API pour s'exécuter sur un vieux (wiki).

Le grand Soleil du document concernant JDK Incompatibilités dans J2SE 5.0 depuis 1.4.2 (et Java SE 6 compatibilité avec J2SE 5.0 trop) décrit la compatibilité de JDK comme suit:

JDK 5.0 est à la hausse compatible au niveau binaire avec Java 2 SDK v1.4.2 sauf pour les incompatibilités énumérés ci-dessous. Cela signifie que, sauf pour les incompatibilités, les fichiers de classe construit avec la version 1.4.2 de compilateurs exécuter correctement dans le JDK 5.0.

Je suppose que les rédacteurs de documentation ont confondu les termes "à la hausse" et "en arrière", à la compatibilité de cette phrase. Ils décrivent un "arrière", à la compatibilité, mais l'appel de cette fonction comme "la hausse" la compatibilité.

Est-ce une faute de frappe, erreur ou destinés terme ici? Est JDK "vers le haut" ou "en arrière" compatible?

Answer 1

Notez que pour que quelque chose pour être rétrocompatible il doit y avoir une contrepartie qui transmet compatible (intentionnellement ou non). Par exemple: les lecteurs de DVD compatible avec les CD ou du CD-rom compatible avec les DVD lecteurs?

Dans ce cas, cela dépend de si vous regardez le compilateur (ou le pseudo-code qu'il génère) ou la machine virtuelle.

Le compilateur n'est pas compatible parce que le bytecode généré avec Java5 JDK ne s'exécutent pas dans Java 1.4 jvm (sauf si compilé avec l' -target 1.4 drapeau). Mais la JVM est rétro-compatible, comme il peut exécuter d'anciens bytecode.

Donc je suppose qu'ils ont choisi de prendre en considération la compatibilité du point de vue de javac (comme c'est la partie spécifique à la JDK), ce qui signifie que le bytecode généré peut être exécuté dans les futures versions de la jvm (qui est plus liée à la JRE, mais aussi inclus dans le JDK).

En bref, nous pouvons dire:

• Du JDK sont (généralement) compatible.
• JRE sont (généralement) rétro-compatible.

(Et il sert aussi comme une leçon qui doit être apprise il y a longtemps: le peuple de l'écriture de compilateurs sont généralement à droite, et nous, les personnes utilisant un mal xD)

Par ailleurs, ne doit-il pas plus logique de la paire vers l'arrière/vers l'avant et vers le bas/vers le haut plutôt que de le mélanger vers le haut?

Answer 2

L'extension des réponses à inclure la plus récente de Java ...

Java SE 7 et JDK 7 Compatibilité

Citations d'Oracle sans date page:

La compatibilité est une question complexe. Ce document traite de trois types de les incompatibilités potentielles relatives à une version de Java plate-forme:

1. Source: la Source de problèmes de compatibilité de traduire le code source Java dans des fichiers de classe, y compris si oui ou non code compile à tous les.
2. Binaire: la compatibilité Binaire est définie dans Le Langage Java Specification qu'à la préservation de la capacité de relier sans erreur.
3. Comportementales: Comportemental compatibilité de la sémantique du code qui est exécuté au moment de l'exécution.

... et

Les incompatibilités entre Java SE 7 et Java SE 6, Java SE 7 est fortement compatible avec les précédentes versions de la plate-forme Java. Presque tous les programmes d'exécution de Java SE 7 sans la modification. Cependant, il existe quelques légères source potentielle et binaire des incompatibilités dans la JRE et JDK qui impliquent des rares les circonstances et le "coin des affaires", qui sont documentées ici pour l'exhaustivité.

Java SE 7 Incompatibilités dans la Langue, la JVM, ou de l'API Java SE

... et

Les incompatibilités entre le JDK 7 et JDK 6

JDK 7 Incompatibilités dans javac, en point d'accès, ou de l'API Java SE

(Pas de préambule, il y a juste une liste d'incompatibilités.)

Answer 3

En arrière seulement. Avant compat ("accepter gracieusement d'entrée prévu pour les versions ultérieures de lui-même"), il faudrait 1.5 JVM pour être en mesure d'exécuter 1.6 code compilé, qui elle ne peut pas.

En arrière exige "si on peut travailler avec des entrées générées par un appareil plus ancien", ce qui est vrai comme une JVM 1.6 pouvez exécuter 1.5 code compilé.

Chaque version du JDK/JRE coïncide avec une version du bytecode Java. Chaque compilateur génère un code spécifique d'une version bytecode. Chaque JVM comprend une version et toutes les versions antérieures spécifique d'une version bytecode.

Lorsque la JVM charge une classe, il vérifie la version bytecode et si c'est > que la Jvm dernières compris version, vous obtiendrez une Erreur. (ClassVersionError ou quelque chose).

Answer 4

Java (VM) est compatible avec les versions antérieures. Le code créé par Java 1.4.2 fonctionnera sur 1,5 et 6 machines virtuelles. Le compilateur JDK n'est pas compatible avec les versions antérieures. Le code ne peut donc pas être compilé par java 1.5 pour fonctionner sous 1.4.2 par exemple.

Answer 5

JDK est compatible avec les versions antérieures de wiki.