On 14 June 2012 22:24, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Thu, Jun 14, 2012 at 05:31:23PM +0100, sebb wrote: >> On 14 June 2012 02:15, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: >> > Hello. >> > >> >> > [...] >> > >> > The following: >> > >> >> >> > I should be able to do all combinations, i.e.: >> >> >> > 1. Compile with javac 1.6 and run with java 1.6 >> >> >> > 2. Compile with javac 1.7 and run with java 1.7 >> > >> > is achieved by those respective commands: >> > >> > $ JAVA_1_6_HOME=/usr/lib/jvm/java-6-sun mvn -X -Pjava-1.6 clean test >> > $ JAVA_1_7_HOME=/usr/lib/jvm/java-7-openjdk-amd64 mvn -X -Pjava-1.7 clean >> > test >> > >> > IIUC: >> > JAVA_x_y_HOME is used to locate the "javac" executable >> >> Sort of. >> >> > -Pjava-x.y selects the language level >> >> -P selects the profile, which uses the relevant JAVA_1_n_HOME variable >> to locate the relevant Java installation. >> These variable were introduced specifically to support the java-x.y profiles. > > The profile also sets "commons.compiler.compilerVersion", and I inferred > that this would define which version of the language is accepted by the > compiler. Is that correct?
It's used to set <compilerVersion> for the maven-compiler-plugin See: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerVersion Also: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html The source and target properties are used to set the language version. >> >> > JAVA_HOME has no effect >> > >> > This, however, >> > >> >> >> > 3. Compile with javac 1.6 and run with java 1.7 >> > >> > is not so easy. To run the tests with 1.7, one needs >> > >> > $ JAVA_1_6_HOME=/usr/lib/jvm/java-6-sun mvn >> > -Dcommons.surefire.java=/usr/lib/jvm/java-7-openjdk-amd64/bin/java -X >> > -Pjava-1.6 clean test >> >> >> > [...] >> > >> > Much to my surprise, this >> > >> > $ JAVA_1_7_HOME=/usr/lib/jvm/java-7-openjdk-amd64 mvn >> > -Dcommons.surefire.java=/usr/lib/jvm/java-6-sun/bin/java -X -Pjava-1.7 >> > clean test >> > >> > (i.e. using java 1.6 to run classes compiled with javac 1.7) also works! Is >> > that expected? [I thought I'd get the "incompatible major.minor version" >> > exception.] >> >> Unless you are using an updated version of the parent pom, the profile >> java-1.7 does not exist - this should report an error, but it might >> get lost in the -X output - so the compilation will use your default >> java compiler. > > Excerpt (with line numbers) of "commons-parent-24.pom": > --- > 858 <profile> > 859 <id>java-1.7</id> > 860 <properties> > 861 <commons.compiler.fork>true</commons.compiler.fork> > 862 > <commons.compiler.compilerVersion>1.7</commons.compiler.compilerVersion> > 863 > <commons.compiler.javac>${JAVA_1_7_HOME}/bin/javac</commons.compiler.javac> > 864 > <commons.surefire.java>${JAVA_1_7_HOME}/bin/java</commons.surefire.java> > 865 </properties> > 866 </profile> > --- Oops, should have double-checked - I thought we had not yet added 1.7. Anyway my reasoning was wrong, sorry. Actually it's the java target version that matters here; the Java 1.7 compiler can generate code for Java 1.5 if the target is set to 1.5. However, the Java 1.7 compiler will reference the 1.7 runtime libraries, so if the 1.5 source code accidentally references something added since 1.5, it may still compile OK. And running against the 1.7 library will probably work too. That is why it's important to try and build and test the source code using the relevant compiler - it's actually the run-time libraries that matter, not generally the compiler version itself. For code that targets 1.5: - one should compile and test on 1.5, 1.6, 1.7. That ensures users with 1.5+ can run the code OK from source - also compile on 1.5 and test on 1.6 and 1.7. That ensures users with 1.6+ can run the 1.5 jar. > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
