I'd like to know if I can develop my program with the current JRE 7u45 and later run it on an AS400 with IBM J9 VM build 2.4, JRE 1.6.0. Or will I have to use the 1.6.0 JRE to develop my program? As long as I don't use commands that were introduced later the program should work, shouldn't it?
5 Answers
If you are careful enough with the APIs, you can make the Java 7 compiler produce Java 6-compliant bytecode, but it is not the default behavior.
I must add that this doesn't seem like a wise way to move; the APIs change in subtle as well as prominent ways and setting the "compliance level" parameters on the Java compiler will not prevent you from calling any methods which do not exist in JDK 6.

- 195,646
- 29
- 319
- 436
-
I have been recently in the same problem. Marko is right about 'being careful with the APIs', if your developers have any bad practice (using sun.* or com.sun.*, etc. packages included in the JDK) you can have a problem once in production. Have a dry run compiling and running your app with an equivalent IBM JDK in your development machine just to be on the safe side – Jorge_B Jan 16 '14 at 09:25
-
@Jorge_B Another pitfall is that some minor methods get added to the core APIs (like String) and it is not very easy to avoid them all. – Marko Topolnik Jan 16 '14 at 09:26
-
Won't the api's change based on `-target` level? So shouldn't the Java6 API be the same with `-target 1.6` ? – vikingsteve Jan 16 '14 at 09:27
-
@Marko True, but Steve will find it easily setting source 1.6 as well as target 1.6 in his compiler settings. The real problem comes from bad practices by the developers. Say they have used `sun.misc BASE64Encoder` or something like that; Sun JDK will just produce a warning, while IBM JDK may or not fail in production (maybe that class is not present in IBM implementation). This must be detected as soon as possible and replaced with another option (maybe an Apache Commons class or whatever) – Jorge_B Jan 16 '14 at 09:30
-
If I use `javac -source 1.6 -target 1.6 MyJavaFile.java` to generate the 1.6 compatible code with the current jdk, will I have to install the older version too or is the current jdk able to generate the code itself? – Steve Jan 16 '14 at 09:30
-
@Steve Neither the "source compliance level" nor the "target compliance level" have anything to do with the JDK APIs. They just make sure the resulting bytecode is compliant with a Java 6 runtime. If you compile against JDK 7 APIs, then that's what you would need at runtime as well---unless you carefully constrain yourself to just the subset of the JDK 7 which existed in JDK 6. Not worth it, in my opinion. – Marko Topolnik Jan 16 '14 at 09:33
-
@Jorge_B No, setting those flags will not stop your code calling methods which were added in JDK 7. – Marko Topolnik Jan 16 '14 at 09:34
-
1Worth mentioning here is that if you use maven, the animal-sniffer plugin solves the problem you mention. – Brian Roach Jan 16 '14 at 09:36
-
@BrianRoach Good to know! It can sniff out a dolphin among the horses, I presume :) – Marko Topolnik Jan 16 '14 at 09:40
-
There are two issues at play:
1) You can't use any new Java 7 features and attempt to generate 1.6 bytecode. Compiling with -source 1.6 -target 1.6
solves this problem. It will puke if you've done so (e.g. used the diamond operator; List<String> foo = new ArrayList<>()
)
2) You can't use new classes or new methods added to classes in 1.7. It will compile fine, then fail at runtime on the 1.6 JVM. This is a trickier problem. Using maven to build your project plus the animal-sniffer
plugin solves this issue:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<compilerArgument>-Xlint:all</compilerArgument>
</configuration>
</plugin>
<plugin>
<!-- ensure that only methods available in java 1.6 can
be used even when compiling with java 1.7+ -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>1.9</version>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java16</artifactId>
<version>1.1</version>
</signature>
</configuration>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

- 76,169
- 12
- 136
- 161
I do this daily.
The best way to be absolutely certain that the code will work as written without accidentally using features not present is to use java 6 for development. For eclipse that is installing a java 6 JDK and adding it to the Eclipse JRE preferences.
Note that the built in File support does not support CCSID's. Use IFSFile in jt400.jar instead.
Also, if you use JAVA or RUNJVA to invoke your program, you can use SystemDefaults.properties to provide system properties and JVM arguments. Check infocenter.

- 73,784
- 33
- 194
- 347
You should use JDK
instead of JRE
.
Also, use 1.6.0
instead of 1.7
because there are some features in version 1.7 that version 1.6 doesn't support.

- 3,930
- 3
- 29
- 57
-
I meant JDK, what else, but OK so I'll work with 1.6, thx for the information. – Steve Jan 16 '14 at 09:20
-
Not entirely true. From the [Java Docs](http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html) – radimpe Jan 16 '14 at 09:24
-
-
The 1.7 compiler is fully capable of generating 1.6 compliant bytecode; `-source 1.6 -target 1.6` – Brian Roach Jan 16 '14 at 09:34
While you compile the program you need to use the "-target" flag and set it to 1.6

- 1,527
- 2
- 16
- 22
-
Consider adding some detail to your answer... like adding a reference to the JAVA Doc for this? – radimpe Jan 16 '14 at 09:25
-
@radimpe here http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javac.html – Silviu Burcea Jan 16 '14 at 09:29
-
@SilviuBurcea: I was merely pointing out that the answer was not that useful without something to back it up with. I've actually added the JAVA docs link on a different comment above (for 1.7, as asked by the OP). Thanks. – radimpe Jan 16 '14 at 09:30
-
You would also need to set the `-source` flag, and that still doesn't prevent you from using new classes / methods added in Java 7 (It will compile fine, then fail at runtime on the 1.6 JVM) – Brian Roach Jan 16 '14 at 10:05