Backward compatibility -- what does it really mean?

[Chan Ag]

Hi,

I am not too sure what exactly Java's backward compatibility means. Java here refers to Java runtime, not the programming language itself. Would that be right?

Does it mean that the bytecode of an earlier version of javac can be executed on a higher version of Java runtime? So is the only guarantee that can be made is if it did not break at runtime with a previous version of Java, it will also not break at runtime with a newer version of Java? Does that also include that the runtime behavior of the bytecode will be the same in the newer version of Java runtime.

Does it also mean that the source files that compiled without any compilation errors will also compile without any compilation errors with a newer version of javac?

Or is there more to backward compatibility?

Sorry, I am confused about this and I just wanted to make sure that going forward I won't be confused about it anymore.

Thank you.
Chan.

[Winston Gutkowski]

Chan Ag wrote:I am not too sure what exactly Java's backward compatibility means. Java here refers to Java runtime, not the programming language itself. Would that be right?

No.

Does it mean that the bytecode of an earlier version of javac can be executed on a higher version of Java runtime?

Yes.

So is the only guarantee that can be made is if it did not break at runtime with a previous version of Java, it will also not break at runtime with a newer version of Java? Does that also include that the runtime behavior of the bytecode will be the same in the newer version of Java runtime.

Depends on what you mean by "behaviour". If you mean "will it do the same thing?", the answer is 'yes'; if you mean "will it do it the same way?" the answer is 'no' ... and if you think about it, it's the only thing that can possibly be guaranteed. A bytecode command may well have been updated by a new version of the JVM for a platform (eg, to make it run quicker), but its behaviour must be the same as it was before - although with all the changes that have taken place in the memory model, I'm not sure even that can be absolutely guaranteed. Maybe it's better to say that its effect must be the same

Does it also mean that the source files that compiled without any compilation errors will also compile without any compilation errors with a newer version of javac?

I think so, but I'm not sure it's guaranteed. There's certainly no guarantee that it won't compile without warnings though.

Or is there more to backward compatibility?

Quite a bit, but it's more of a refactoring exercise than a compiler/JVM one. In theory, a .java (source) and .class (bytecode) file from version 1 should compile (javac) and run (java) in version 8.

At least that's the way I understand it.

Winston

[Chan Ag]

Thanks, Winston. I finally understand it ( I think ).

[Paweł Baczyński]

Winston Gutkowski wrote:I think so, but I'm not sure it's guaranteed. There's certainly no guarantee that it won't compile without warnings though.

There is one example when they introduced a change to the language that broke earlier code. It's in Java 1.5 when they introduced enum keyword.
This code would compile just fine in Java 1.4:

public class Example {
	int enum;
}

Starting with version 1.5 you have to specifically tell the compiler that you want to compile your code under "old" rules (via source -1.4 parameter) if you want to use enum as an identifier.
And you would get a warning

[Winston Gutkowski]

Pawel Pawlowicz wrote:There is one example when they introduced a change to the language that broke earlier code. It's in Java 1.5 when they introduced enum keyword.

GOOD spot. I hadn't thought about keywords.

There's also another one I can think of - much more uncommon, but slightly more naughty I reckon: Before 1.5, BigDecimal did not have a toPlainString() method, but it was how toString() worked. As a result of 1.5, the behaviour of toString() was transferred to toPlainString(), and toString() was changed to work more like printf("%f") - ie, to display the value in "scientific" form in some cases.

Winston

[Jesper de Jong]

Chan Ag wrote:Does it also mean that the source files that compiled without any compilation errors will also compile without any compilation errors with a newer version of javac?

Backward compatibility does not only mean binary compatibility (i.e. code compiled with an older JDK runs on a newer JVM), but also source compatibility; so yes, source code that compiled with an old JDK should compile without errors on a new JDK. Sun, and now Oracle, has always been extremely careful to make sure new Java versions are backward compatible. That has advantages: it makes it easier for people to upgrade to a new Java version, because they should not have to change anything, but it also has disadvantages: it puts a brake on the pace with which the Java language can adopt new features, and old, deprecated classes and methods never get deleted, cluttering up the Java API with more and more old junk with each new version.

There are a number of minor incompatibilities, such as the enum keyword added in Java 1.4; besides that there are some other incompatibilities, for example some bugs in the Java compiler have been fixed so that code which compiled on for example JDK 6 might not compile anymore on JDK 7 or 8 (it shouldn't have been compileable on JDK 6, but it did because of a compiler bug). Every new Java version comes with a page which explains the incompatibilities in detail. For example:

Compatibility Guide for JDK 8
Java SE 7 and JDK 7 Compatibility
Java SE 6 Compatibility

[Chan Ag]

Thanks for those links, Jesper.

I spent some time this morning going through JDK 7 Incompatibilities with JDK 6 in javac, in HotSpot, or Java SE API .

There are many changes done to generic type inference, I see. The compiler has become smarter than it was in identifying corner cases that could lead to heap pollution (an example of one such case is RFE 6638712 - http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities, http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6638712 ).