Is JDK "upward" or "backward" compatible?

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?

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.)

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).

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.

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