Login/Register
Is JDK "upward" or "backward" compatible?
Asked Answered
Solved javabackwards-compatibilitybinary-compatibilityforward-compatibility
N

8

80

Backward binary compatibility (or downward compatibility) - an ability of clients built with an old version of library API to run on a new one (wiki).

Upward binary compatibility (or forward compatibility) - an ability of clients built with a new version of library API to run on old one (wiki).

The general Sun's document about JDK Incompatibilities in J2SE 5.0 since 1.4.2 (and Java SE 6 compatibility with J2SE 5.0 too) describes the compatibility of JDK as following:

JDK 5.0 is upwards binary-compatible with Java 2 SDK, v1.4.2 except for the incompatibilities listed below. This means that, except for the noted incompatibilities, class files built with version 1.4.2 compilers will run correctly in JDK 5.0.

I suppose that documentation writers have mixed up terms "upward" and "backward" compatibility in this sentence. They describe a "backward" compatibility, but call this feature as "upward" compatibility.

Is this a typo, mistake or intended term here? Is JDK "upward" or "backward" compatible?

Nuthouse answered 14/1, 2011 at 15:24 Comment(3)
BTW: You should really be looking at Java 6 as Java 5.0 has been EOL for some time. – Kameko
Java 6 is described in documentation as "upwards binary-compatible" too. – Nuthouse
For backwards incompatible only: #1655423 – Zakarias
S
112

Note that for something to be backwards compatible there must be a counterpart that is forwards compatible (either intentionally or unintentionally). For example: are the DVD readers backwards compatible with CD's or are the CD's forward compatible with DVD readers?

In this case, it depends if you look at the compiler (or the bytecode it generates) or the virtual machine.

The compiler is not backwards compatible because bytecode generated with Java5 JDK won't run in Java 1.4 jvm (unless compiled with the -target 1.4 flag). But the JVM is backwards compatible, as it can run older bytecodes.

So I guess 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.

(And it also serves as a lesson that should be learnt long ago: the people writing the compilers are usually right, and we the people using them wrong xD)

By the way, doesn't it make more sense to pair backward/forward and downward/upward rather than mixing them up?

Senegal answered 14/1, 2011 at 15:34 Comment(0)
P
22

Extending answers to include the most recent Java …

Java SE 7 and JDK 7 Compatibility

Quotes from Oracle's undated page:

Compatibility is a complex issue. This document discusses three types of potential incompatibilities relating to a release of the Java platform:

  1. Source: Source compatibility concerns translating Java source code into class files including whether or not code still compiles at all.
  2. Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link without error.
  3. Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.

… and

Incompatibilities between Java SE 7 and Java SE 6 Java SE 7 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 7 without modification. However, there are some minor potential source and binary incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that are documented here for completeness.

Java SE 7 Incompatibilities in the Language, the JVM, or the Java SE API

… and

Incompatibilities between JDK 7 and JDK 6

JDK 7 Incompatibilities in javac, in HotSpot, or Java SE API

(No preamble there – just a list of incompatibilities.)

Precast answered 14/1, 2011 at 15:24 Comment(0)
T
17

Backward only. Forward compat ("gracefully accept input intended for later versions of itself") would require the 1.5 JVM to be able to run 1.6 compiled code, which it can't.

Backward requires "if it can work with input generated by an older device" which is true as a 1.6 JVM can run 1.5 compiled code.

Each release of the JDK/JRE coincides with a version of Java bytecode. Each compiler produces code of a specific bytecode version. Each JVM understands a version and all earlier versions of a specific bytecode version.

When the JVM loads a class it checks the bytecode version and if it is > than the JVMs latest understood version you'll get an Error. (ClassVersionError or something).

Tarnish answered 14/1, 2011 at 15:38 Comment(0)
F
10

Java (VM) is Backward compatible. Code built by java 1.4.2 will run on 1.5 & 6 VM's. The JDK compiler is not backward compatible. So code cannot be compiled by java 1.5 to run on 1.4.2 for example.

Forseti answered 14/1, 2011 at 15:32 Comment(0)
T
3

JDK is Backward compatible, i.e. Byte Code that complies to 1.4.2 spec will run on Java 5 JVM

Twana answered 14/1, 2011 at 15:30 Comment(0)
I
2

JDK is downwards compatible as per the definition from wiki.

Incommensurate answered 14/1, 2011 at 15:28 Comment(0)
S
1

It should be backward compatible.

Stanwood answered 14/1, 2011 at 15:28 Comment(0)
N
-1

jdk is upward compatible - new version can run on old one

Navada answered 14/1, 2011 at 15:29 Comment(1)
source code and byte code compatibility are difference. – Millenarian

© 2022 - 2024 — McMap. All rights reserved.