Is the JDK compatible up or back?

Question

Backward compatibility with binary files (or down ) - the ability of clients built using the old version of the library's API library to work on the new one ( wiki ).

Bilateral compatibility up / forward ) - the ability of clients built with the new version of the library API to work on the old ( wiki ).

Sun's general JDK document Incompatibility in J2SE 5.0 from version 1.4.2 (and compatibility with Java SE 6 with J2SE 5.0 ) describes JDK compatibility as follows:

JDK 5.0 supports upward binary compatibility with the Java 2 SDK, v1.4.2, with the exception of the incompatibilities listed below. This means that, with the exception of the incompatibilities noted, class files created using compilers of version 1.4.2 will work correctly in JDK 5.0 .

I believe that in this sentence, the authors of the documentation have mixed terms "up" and "back". They describe "backward" compatibility, but call this feature "upward" compatibility.

Is it a typo, mistake, or intended term here? Is the JDK compatible up or back?

Answer 1

Please note that in order for something to be compatible with feedback, there must be an analog that is forward compatible (either intentionally or unintentionally). For example: are DVD media read backwards compatible with CDs or are CDs compatible with DVD readers?

In this case, it depends on whether you are looking at the compiler (or the generated bytecode) or the virtual machine.

The compiler does not support backward compatibility, since bytecode generated with the Java5 JDK will not run in Java 1.4 jvm (unless compiled with the -target 1.4 flag). But the JVM is backward compatible, as it can run high byte codes.

Therefore, I assume that they decided to consider compatibility from a javac point of view (since it is a part specific to the JDK), which means that the generated bytecode may be launched in future releases of jvm (which is more related to the JRE, but also bundled with the JDK )

In short, we can say:

• JDK (usually) compatible in direct mode.
• JRE (usually) backward compatible.

(And it also serves as a lesson to learn for a long time: people who write compilers are usually right, and we humans use them incorrectly xD)

By the way, does it make sense to shift back / forward and down / up, rather than mixing them?

Answer 2

The answer extension includes the latest Java ...

Compatible with Java SE 7 and JDK 7

Quotes from the raw page of Oracle:

Compatibility is a complex issue. This document discusses three types of potential incompatibilities associated with the release of the Java Platform:

• Source : source compatibility issue for translating Java source code into class files, including code that still compiles everything.
• Binary : binary compatibility is defined in the Java Language Specification as preserving the ability to bind without errors.
• Behavioral . Behavioral compatibility includes the semantics of code that runs at runtime.

... and

Incompatibility between Java SE 7 and Java SE 6 Java SE 7 is highly 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 sources and binary incompatibilities in the JRE and JDK, which are circumstances and “corner cases” that are described here for completeness.

Java SE 7 Incompatibility in Language, JVM, or Java SE API

... and

Incompatibility between JDK 7 and JDK 6

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

(There is no preamble there - only a list of incompatibilities.)

Answer 3

Just back. Direct compatibility ("gracefully accept input intended for later versions") will require that 1.5 JVMs be able to run 1.6 compiled code that it cannot.

In the reverse order, it is required "if it can work with the input generated by the older device", which is true, since the 1.6 JVM can execute 1.5 compiled code.

Each version of the JDK / JRE is the same as the Java bytecode version. Each compiler generates code for a specific version of the bytecode. Each JVM understands the version and all earlier versions of a particular bytecode version.

When the JVM loads the class, it checks the bytecode version and, if it is> than the version with a clear JVM interface, you will receive an error message. (ClassVersionError or something else).

Answer 4

Java (VM) backward compatibility. The code created by java 1.4.2 will run on 1.5 and 6 virtual machines. The JDK compiler does not support backward compatibility. Therefore, the code cannot be compiled by java 1.5 to run on 1.4.2, for example.

Answer 5

JDK backward compatibility, i.e. bytecode conforming to specification 1.4.2, will run on Java 5 JVM

Answer 6

JDK is compatible as defined in the wiki.

Answer 7

It must be backward compatible.

Answer 8

jdk upward compatibility - new version may work on old version