Does the bytecode depend on the version of Java it was created with?
7 Answers
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.

- 698,415
- 94
- 811
- 1,216
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

- 168,117
- 40
- 217
- 433
-
Note that JDK 1.8 says that compiling for target 1.5 is deprecated, and JDK 1.9 will remove target 1.5 support completely: http://openjdk.java.net/jeps/182 ...but however, on JDK 1.9, compilation for older versions is easier because bootclasspath is not required: http://openjdk.java.net/jeps/247 – juhist Jul 05 '17 at 13:29
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.

- 28,272
- 7
- 61
- 66
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.

- 77,184
- 16
- 165
- 176
-
1@birryree: New versions are backward compatible. Old versions are not forward compatible. This will make more sense, what say you? – Adeel Ansari Oct 31 '10 at 05:37
-
1@Adeel: I'd say it is your comment that is nonsensical. An applet created in Java 1.1 should run just fine in Java 1.6 barring regression bugs. – Andrew Thompson Oct 31 '10 at 06:23
-
@Andrew: I am saying exactly the same thing. Did I put it somehow different? New versions are backward compatible, means 1.1 applet should run just fine in 1.6. – Adeel Ansari Oct 31 '10 at 06:50
-
@Adeel "1.1 applet should run just fine in 1.6" is something I believe we all agree on (with minor caveats already mentioned), but birryree's words would have meant that to my eyes, whereas your statement meant the opposite. At least as far as I understand it! How about we stick to "1.1 applet should run just fine in 1.6" to avoid confusion? ;) – Andrew Thompson Oct 31 '10 at 07:49
-
@Andrew: You started me to doubt my own sentence. Yes, we should stick to your suggestion. The problem here is, I am not native English speaker, so its likely that you are right. :) – Adeel Ansari Oct 31 '10 at 08:02
-
Are you taking about new versions of JVMs being backward compatible with old code? Or old versions of code being forward compatible with JVMs? – Muhammad Alkarouri Nov 06 '10 at 17:00
-
@Muhammad - I'm talking about the compatibility of the compiled bytecode. For source code, source is also forward compatible (code in Java 1.4.2 compiles in Java 5 and Java 6, for example), but the reverse is not necessarily true if you use any features added in later releases (like using generics and trying to compile with Java 1.4.2). – wkl Nov 06 '10 at 17:11
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.

- 1
- 1

- 39,541
- 12
- 93
- 133
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.

- 196,001
- 113
- 385
- 569