Develop Reference

Version issue in custom jar

I am posting this question as I have limited resources to test or confirm by my own.
Problem statement : I have an old custom Jar working with java 1.6. We don't have source code as well.
To fix one of the issue we updated 2 .class file of this jar using 7-zip.The code change was just to update the existing loggers with more meaningful messages.
These 2 .class file compiled with java 1.7.
Now the questions is whether this jar will work correctly with java 1.6 or will generate java version issue as 2 of the .class files are compiled with java 1.7.
Note - I know it's easy to test this rather then asking here but my test environment is only supporting java 1.8 and it's working perfectly but whether it will run with java 1.6 or not I can't test.

If you compile using: javac Foo.java where that javac is from a JDK1.7 installation, and you then attempt to run the class file that results on a JDK1.6, it will not work.
However, all you need to do is this:
javac -source 1.6 -target 1.6 Foo.java, and then it will, unless you used features from 1.7. If you use language features (I can't think of any, so I doubt it), it won't compile, and thus you know. If you use API, it will compile and you won't know. There is no easy solution to this other than compiling with JDK1.6 (or compiling with javac7 against a bootcp of JDK1.6, but you need to download and install a JDK1.6 to get that; might as well just use javac6 then).

Binary Compatibility
The class file version for Java SE 7 is 51, as per the JVM Specification, because of the invokedynamic byte code introduced by JSR 292. Version 51 class files produced by the Java SE 7 compiler cannot be used in Java SE 6.
Java SE 7 is binary-compatible with Java SE 6 except for the incompatibilities . Except for the noted incompatibilities, class files built with the Java SE 6 compiler will run correctly in Java SE 7.
Friends Words ...
The compiler is not backwards compatible because bytecode generated with Java7 JDK won't run in Java 1.6 jvm (unless compiled with the -target 1.6 flag). But the JVM is backwards compatible, as it can run older bytecodes.
So they chose to consider the compatibility from the point of view of javac (as it is the part specific to the JDK), meaning that the bytecode generated can be run in future releases of the jvm (that is more related to the JRE, but also bundled in the JDK).
In brief, we can say:
JDK's are (usually) forward compatible.
JRE's are (usually) backward compatible.
Java Says
Cross-Compilation Options
By default, classes are compiled against the bootstrap and extension classes of the platform that javac shipped with. But javac also supports cross-compiling, where classes are compiled against a bootstrap and extension classes of a different Java platform implementation. It is important to use -bootclasspath and -extdirs when cross-compiling; see Cross-Compilation Example below.
-target version
Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).
The default for -target depends on the value of -source:
If -source is not specified, the value of -target is 1.7
If -source is 1.2, the value of -target is 1.4
If -source is 1.3, the value of -target is 1.4
If -source is 1.5, the value of -target is 1.7
If -source is 1.6, the value of -target is 1.7
For all other values of -source, the value of -target is the value of -source.
-bootclasspath bootclasspath
Cross-compile against the specified set of boot classes. As with the user class path, boot class path entries are separated by colons (:) and can be directories, JAR archives, or ZIP archives.
For More about Cross-Compilation look at
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#crosscomp-options
Better than me at
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html

The code base for Java 7 and versions of Java 6 is very similar and even shares many of the same bugs. e.g. the was a well known bug in Java 7 when it was released to do with loop optimisation and people suggested waiting for it to be fixed before migrating. The interesting thing was the bug was also in Java 6, the only difference was that the optimisation was on by default in Java 7 and off by default in Java 6.
Most of the performance improvements in Java 7 were back ported into Java 6.

webapp compiled with jdk8 running in Tomcat 7 where jdk7 is only installed [duplicate]

Does the bytecode depend on the version of Java it was created with?

If I compiled a java file in the newest JDK, would an older JVM be able to run the .class files?
That depends on three things:
The actual Java versions you are talking about. For instance, a 1.4.0 JVM can run code compiled by a 1.4.2 compiler, but a 1.3.x JVM cannot1.
The compilation flags used. There is a -target compiler flag that tells it to generate code that will run on an older (target) JVM. And the -source compiler flag tells it to only accept the older JVM's language features. (This approach won't always work, depending on the Java language features used by your code. But if the code compiles it should work.)
The library classes that the class file uses. If it uses library classes that don't exist in the older class libraries, then it won't run ... unless you can include a JAR that back-ports the classes2. You can avoid this problem by using the -bootclasspath option to compile your code against the APIs of the older version of Java.
Does the bytecode depend on the version of the java it was created with?
Yes, modulo the points above.
1 - The Java 8 JVMS states this: "Oracle's Java Virtual Machine implementation in JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. JDK releases 1.1.* support class file format versions in the range 45.0 through 45.65535 inclusive. For k ≥ 2, JDK release 1.k supports class file format versions in the range 45.0 through 44+k.0 inclusive."
2 - A backport could be problematic too. For example: 1) Things which depend on native code support would most likely require you to implement that native code support. 2) You would most likely need to put any back-port JAR file onto the bootclasspath when you run the code on the older JVM.

Does the bytecode depend on the version of the java it was created with?
Normally yes. But by using the -source, -target and -bootclasspath options, a 1.7+ compiler can be used to create binaries that are compatible with Java 1.1

First and foremost all java files have a version byte in the class header. Older jvms won't load classes with newer versions, regardless of what features they have.

JVM bytecode is forward compatible between major JVM version, but not backward compatible. However, for the best information you will have to read the JVM release notes because they typically indicate how backward compatible the bytecode is.
Edit clarification since this caused discussion in the comments
JVM bytecode is forward compatible, such that bytecode from one JVM is compatible with with later JVM releases. For example, you can take bytecode from the 1.4 JVM and run it in Java 5 or Java 6 JVM (aside from any sort of regression issues as pointed out by Andrew).
JVM bytecode is not backward compatible between JVMs, such that bytecode from a JVM is not guaranteed to work in a previous release of the JVM, as would be the case if you were attempting to run code compiled for Java 6 in a 1.4.2 JVM.

Does the bytecode depend on the version of the java it was created with?
Yes.
If I compiled a java file in the newest JDK, would an older JVM be able to run the .class files?
No. But the opposite will work, most likely. You might like see this interesting thread, it talks about backporting Java.

No, unless you specify as target the old JVM.
Eg.with Java 6 you can compile and run in Java 1.4 using:
javac -target 1.4 SomeClass.java
Obviously the source code should be 1.4 compatible.

You can compile classes that are older-version JVMs compatible if you don't use features available in higher JVMs.
javac -target 1.5 MyJava.java
javac -target 1.4 MyJava.java

what's the difference between -source and -target compatibility?

When using the Java compiler (javac), we can specify two kinds of compatibility. One is using -source and the other is using -target. What is the difference between these two?
For example, -source 1.5 and -target 1.6?
Also, is there any case where we use a different source and target compatibility level?

From the javac docs:
-source Specifies the version of source code accepted.
-target Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM.
In your example:
-source 1.5 and -target 1.6
This would be used to make sure that the source code is compatible with JDK 1.5, but should generate class files for use on JDK 1.6 and later.
Quite why you would do this is another matter.

The -source indicates what level of compliance your source code has: are you using Annotations? Then you would need at least 1.5; are you using #override on interface implementations, you would need 1.6 etc
The -target specifies what Java version you want to be able to run your classes on. You could use a Java SE 7 compiler and compile to run on Java SE 1.5.

This is mostly useful to produce a jar file working with an older version of Java.
I believe that so far all JDKs are able to execute older version too, so there is no real reason to have target larger than source.
It does however make sense to set target to e.g. 1.6 when using a 1.7 JDK.
I'm not sure, but I believe it could work in some situations to compile a 1.7 java code using a 1.7 compiler to a 1.6 jar, for example expressions such as
ArrayList<Integer> foo = new ArrayList<>();
that are only valid in 1.7+ source version should compile to 1.6 compatible byte code. But I have not verified whether the compiler will actually do this. Unfortunately, this doesn't seem to be implemented in practise.

Many versions of JDK: How do I specify which one is used?

I have installed many versions of the JDK: 1.4.2, 1.5 and 1.6.
How do I specify which version of the JDK is used when compiling using Ant?

Two solutions:
Specify the full path in your command:
for example /opt/java/jdk16/bin/javac ... on Linux
Use the -source and -target arguments of the javac command. This allows you specify the source code level and targeted JRE version
Also note:
Some Linux distributions can include tools to specify which JDK version to use by default.
Using -source and -target checkes that your language constructs are compliant with the targeted runtime, but does NOT check that core classes are compatible. This means that compiling with -source 1.4 on a JDK 1.6 will be just fine, even if you use String.isEmpty() which appeared in Java 6. This might lead to errors at runtime

javac -source 1.4 -target 1.4 YourFile.java
-source release
Specifies the version of source code accepted. The following
values for release are allowed:
1.3 the compiler does not support assertions, generics, or other
language features introduced after JDK 1.3.
1.4 the compiler accepts code containing assertions, which were
introduced in JDK 1.4.
1.5 the compiler accepts code containing generics and other
language features introduced in JDK 5. The compiler defaults to the
version 5 behavior if the -source flag is not used.
5 Synonym for 1.5
Here is the relevant documentation.
http://download.oracle.com/javase/1,5.0/docs/tooldocs/windows/javac.html

Use the Ant <javac> task<source> and/or <target> attributes. Valid values can be from 1.1 to 1.7, with 5, 6, and 7 valid aliases for 1.5, 1.6 and 1.7. Also, the <executable> attribute can be used to set which java javac compiler is used. For example:
<javac source="1.4" target="1.4" executable="c:\java1.6\bin\javac.exe"/>

Java 5-compiled binaries on Java 1.3 runtime

May I know if there are any issues running a Java 5-compiled code (with Java 1.3 source/target compliance) on a Java 1.3 JVM?
I know this is quite odd, but most of our customers are on Java 5 but we are restricted by a few still on Java 1.3 due to conditions beyond our control. Our CI tool uses Java 5 compiler but we set our source and target compliance to Java 1.3 for backward compatibility. We are not using Java 1.3 for CI because there are unit tests that does not compile on 1.3.
Will this be an issue?
Thank you in advance!
Cheers,
- Paul

The only way to get the compiler to check that source in your app. only uses 1.3 methods is to specify a -bootclasspath pointing to a 1.3 rt.jar. Note you can get that from a 1.3 JRE, it does not require a 1.3 SDK/compiler. Of course, specify a -target of 1.3.

The biggest problem you will have is that while the JVM generated byte code will be compliant with 1.3, the JDK you're compiling against is Java 5. It is very easy to use a class, or more likely, a method that exists in Java 5, but not in the 1.3 JDK. This code will compile fine but will fail to run on a 1.3 runtime.