options source et cible javac

Java est rétrocompatible. Vous utilisez l'option-source pour spécifier la version java utilisée pour la compilation et vous utilisez l'option-target pour spécifier la version java la plus basse à prendre en charge. par exemple. Si je spécifie une cible de 1.4, mon programme ne pourra pas s'exécuter sur java 1.3 ou inférieur. voir la documentation javac suivante pour plus d'informations. en particulier la section sur Options de compilation croisée

• source: La version que votre code source nécessite pour compiler.
• target: La version JRE la plus ancienne que vous souhaitez prendre en charge.

Assurez-vous également de définir bootclasspath pour vous assurer que votre programme fonctionnera sur les anciennes machines virtuelles.

À Partir de la javac documentation:

Exemple de compilation croisée

L'exemple suivant utilise javac pour compiler du code qui s'exécutera sur une machine virtuelle 1.6.

C\:>javac -source 1.6 -target 1.6 -bootclasspath C:\jdk1.6.0\lib\rt.jar -extdirs "" OldCode.java

L'option -source 1.6 spécifie que la version 1.6 (ou 6) du langage de programmation Java soit utilisée pour compiler OldCode.java. L'option -target 1.6 garantit que les fichiers de classe générés seront compatibles avec les machines virtuelles 1.6. Notez que dans la plupart des cas, la valeur de la -target option est la valeur de la -source option; dans cet exemple, vous pouvez omettre le -target option.

Vous devez spécifier l'option -bootclasspath pour spécifier la version correcte des classes bootstrap (la bibliothèque rt.jar). Sinon, le compilateur génère ce qui suit attention:

C:\>javac -source 1.6 OldCode.java
warning: [options] bootstrap class path not set in conjunction with -source 1.6

Si vous ne spécifiez pas la version correcte des classes bootstrap, le compilateur utilisera les anciennes règles du langage (dans cet exemple, il utilisera la version 1.6 du langage de programmation Java) combinées avec les nouvelles classes bootstrap, ce qui peut entraîner des fichiers de classe qui ne fonctionnent pas sur l'ancienne plate-forme (dans ce cas, Java SE 6) car la référence à des méthodes inexistantes peut être incluse.

Peter Tseng mentionne beaucoup de points clés à retenir lors de la compilation. En fait, même moi, j'ai fait face à un problème similaire et je veux partager les causes profondes de nombreux problèmes.

J'avais un code source qui devait être compilé et rendu compatible (-source & - target) Java '1.8'. Le code lui-même avait

1. Beaucoup de symbole de marque, donc je me suis retrouvé dans des caractères non reconnus (j'ai dû modifier les paramètres d'encodage d'IntelliJ Idea)
2. Beaucoup de modifications apportées au paquet java.sql.*
3. Utilisation de lot de bibliothèques tierces. M'épargner l'horreur d'expliquer la difficulté de débogage là et bla bla bla.

Après certains changements, je me suis retrouvé avec un code qui avait le même nombre de cas de test JUnit à exécuter. Finalement, je suis tombé sur un java.lang.VerifyError. J'ai été choqué quand j'ai compris qu'une telle erreur se produit lorsque je compile et exécute le code dans les différentes bibliothèques/environnements(ce qui n'était pas le cas).

Ce qui m'a presque manqué, c'est cela, pour honorer le fait que les tests devaient s'exécuter dans un environnement isolé, le Junit et ses cas de test étaient exécutés dans une machine virtuelle fourchue séparée

<target name="runJunit">
    <junit printonsummary="on" 
           haltonfailure="off"
           fork="true"
           forkmode="once">
        <formatter />
        <batchtest />
        <classpath />
    </junit>
</target>

Cela sera évidemment étendu comme un processus séparé et agira comme une application autonome en exécution. Même si l'E couvre les deux processus de manière synchrone, les JVM sont à peu près isolées.

Après Java 1.7, Oracle a introduit une vérification plus stricte et a changé un peu le format de classe to en contient une carte de pile, utilisée pour vérifier que le code est correct. L'exception que j'avais vue était parce qu'une méthode n'a pas de carte de pile valide. J'ai finalement essayé d'inclure beaucoup d'options JVM pour modifier le paramètre, mais en vain.

<jvmarg value="bootclasspath:{env.JAVA_HOME}\jre\bin\rt.jar" prefix="-X"/>

Rien n'a fonctionné. Le seul travail autour était d'inclure

<jvmarg value=":UseSplitVerifier" prefix="-XX"/>

Dans Java 1.7 pour autoriser uniquement la vérification du code octet nominal. Comme cela a été supprimé dans Java 1.8, la seule option était d'utiliser

<jvmarg value="-noverify"/>

JDK1. 8 ne prendra plus en charge-source et-target moins de 1.6

"c:\Program Files\Java\jdk1.8.0_121\bin\javac.exe" -source 1.3 HelloWorld.java
warning: [options] bootstrap class path not set in conjunction with -source 1.3
warning: [options] source value 1.3 is obsolete and will be removed in a future release
warning: [options] target value 1.4 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
4 warnings