11

Has Java always maintained source-code backward compatibility during its development?

More precisely: given two Java versions X and Y with X < Y, is any program for Java X also a valid program for Java Y, with the same semantics? E.g. X = Java 2 (or 1.2 with the old numbering) and Y = Java 5.

Or is there only compatibility at the JVM level: e.g. a class compiled for the JVM 1.2 can be run by the JVM 5?

If it is possible to run Java 2 code on a Java 5 (or 6, or 7), what are the exact steps that I have to follow? Compile directly with a Java 5 compiler? Compile with a Java 2 compiler and run on JVM 5?

Giorgio
  • 5,023
  • 6
  • 41
  • 71
  • 1
    Thanks for the quick answers. I was a bit unsure as to which one I should accept, because several answers were informative. I had to pick one. – Giorgio Apr 03 '12 at 20:26

6 Answers6

5

Sun, and now Oracle, have always been extremely careful with backward compatibility with regards to Java.

Binary compatibility: You should be able to run Java code compiled with older versions on newer versions without modification. There might, however, be small incompatibilities.

Source compatibility: Code originally written for an older JDK version should almost always compile without modification with a newer Java compiler, but there are a number of small incompatibilities. One of them is the enum keyword added in Java 5; on older versions of Java, enum was a valid identifier, but not on Java 5. Also, importing classes from the default package has been removed (I think since Java 1.4). So you can't do:

import SomeClassName;

anymore on Java 1.4 or newer.

In the documentation of every JDK release there is a document about backward compatibility with previous releases, which lists the details.

Jesper
  • 202,709
  • 46
  • 318
  • 350
4

Starting witg Java 1.5 enum became a reserved word. Thus any Java 1.4 source code containing enum became broken starting with 1.5

Steve Kuo
  • 61,876
  • 75
  • 195
  • 257
3

As far as I know JVMs are backwards compatible. A class compiled with JDK 1 will work in the latest JRE 7. The libraires are definitely not 100% compatible. Some methods have been deprecated (and subsequently removed). Some classes changed behavior in (usually) subtle ways which will cause programs to behave differently.

MK.
  • 33,605
  • 18
  • 74
  • 111
  • Is there anything that's been completely removed? I know they like to deprecate stuff, but i can't think of anything that's actually been taken out. – cHao Apr 03 '12 at 19:27
  • Yes :) http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/FontMetrics.html#getDescent() In JDK 1 and perhaps 1.1 this method was by mistake called "getDecent". It was then deprecated and eventually removed :) – MK. Apr 03 '12 at 19:37
  • (come to think of it, I didn't verify that it is removed, perhaps it is still there...) – MK. Apr 03 '12 at 19:37
  • 1.7 docs still list it. Deprecated, of course, but still there. :) – cHao Apr 03 '12 at 19:45
  • Nope my 1.7 install still has it - which really shows how utterly useless the deprecation feature is apart as a "There's a new better method over there" annotation. Fun trivia though :D – Voo Apr 03 '12 at 19:46
  • @Voo - how does that make the deprecation feature itself useless? not removing it is a decision made by Sun, completely orthogonal to the deprecation feature. – jtahlborn Apr 03 '12 at 19:49
  • @jtahlborn Well the deprecation process should ultimately lead to removing old methods. Considering that we can't even remove a wrongly named function that was replaced in 1.1 I think the argument that we will ever replace anything in the JDK is pretty weak. Hence the whole deprecation process is useless - a simple annotation "Newer, better version over there" would have the same effect. – Voo Apr 03 '12 at 19:54
  • Meh. The JDK's decided to maintain backwards compatibility for all time; it'll never delete anything, but at least deprecated methods won't get used as much in new code. – Louis Wasserman Apr 03 '12 at 20:00
  • @Voo - just because Sun/Oracle uses it that way doesn't mean _you_ have to. your argument only holds in the context of the jdk API. – jtahlborn Apr 03 '12 at 20:01
  • @jtahlborn Ah that's what you mean. I wholeheartedly agree, it was never meant as anything but a comment about the deprecation in the JDK. – Voo Apr 03 '12 at 20:04
  • @Voo - in the context of the jdk, i definitely agree. kind of hoping they'd take a major release and just rip out all the cruft. – jtahlborn Apr 04 '12 at 00:32
  • I think the craft that is worth ripping out (like the entire java.util.Date ;) is absolutely impossible to rip out. And small things like getMaxDecent are not worth the trouble. – MK. Apr 04 '12 at 02:39
  • Maybe if there's ever a Java 2.0, stuff like that will not be in it. :) – cHao Apr 04 '12 at 15:40
2

You can always run with a newer version of the JDK then the one used for compilation. The other way around is not possible (unless you compile using the -target parameter).

You might want to read this document (in particular the Cross-Compilation Options section), which explains the target parameter and the default behavior

Robin
  • 36,233
  • 5
  • 47
  • 99
2

You can look at the backward compatibility analysis of the Java (Jre) library classes here: http://abi-laboratory.pro/java/tracker/timeline/jre/

The report is generated by the japi-compliance-checker tool.

enter image description here

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
0

Java is generally compatible with previous releases but anyway it may be a lot f issues with migration. See my article about migration from JDK 6 to 8 for details

Sergey Ponomarev
  • 2,947
  • 1
  • 33
  • 43