Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are there any specific examples of backward incompatibilities between Java versions?

Have there been incompatibilities between Java releases where Java source code/Java class files targeting Java version X won't compile/run under version Y (where Y > X) ?

By "Java release" I mean versions such as:

  • JDK 1.0 (January, 1996)
  • JDK 1.1 (February, 1997)
  • J2SE 1.2 (December, 1998)
  • J2SE 1.3 (May, 2000)
  • J2SE 1.4 (February, 2002)
  • J2SE 5.0 (September, 2004)
  • Java SE 6 (December, 2006)

House rules:

  • Please include references and code examples where possible.
  • Please try to be very specific/concrete in your answer.
  • A class that is being marked as @Deprecated does not count as a backwards incompatibility.
like image 823
knorv Avatar asked Oct 31 '09 16:10

knorv


People also ask

Are all Java versions backwards compatible?

Backward CompatibilityJava versions are expected to be binary backwards-compatible. For example, JDK 8 can run code compiled by JDK 7 or JDK 6. It is common to see applications leverage this backwards compatibility by using components built by different Java version.

What is backward compatibility in Java?

Backward compatible (also known as downward compatible or backward compatibility) refers to a hardware or software system that can successfully use interfaces and data from earlier versions of the system or with other systems.

Is Java 17 backwards compatible?

In general Java is extremely backward compatible. There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them.

Is Java 11 backwards compatible?

Java 11 is backwards compatible with Java 8. So you can swiftly change from Java 8 to 11. If you use some of the packages below, all you need to do is add the replacement dependency to your project. Also, Applets and Java Web Start are completely removed without a replacement.


2 Answers

Compatibility notes for various versions:

  • Java 1.4
  • Java 5
  • Java 6
  • Java 7
  • Java 8

The first major hiccup I remember was the introduction of assert in Java 1.4. It affected a lot of JUnit code.

like image 76
McDowell Avatar answered Oct 02 '22 19:10

McDowell


First of all, Sun actually considers all of the releases you mentioned (other than 1.0 of course) to be minor releases, not major ones.

I am unaware of any examples of binary incompatibility in that time. However, there have been some examples of source incompatibility:

  • In Java 5, "enum" became a reserved word; it wasn't before. Therefore, there were source files that used enum as an identifier that would compile in java 1.4 that wouldn't compile in java 5.0. However, you could compile with -source 1.4 to get around this.

  • Adding methods to an interface can break source compatibility as well. If you implement an interface, and then try to compile that implementation with a JDK that adds new methods to the interface, the source file will no longer compile successfully, because it doesn't implement all of the interface's members. This has frequently happened with java.sql.Statement and the other jdbc interfaces. The compiled forms of these "invalid" implementations will still work unless you actually call one of the methods that doesn't exist; if you do that, a MissingMethodException will be thrown.

These are a few examples I can recall off of the top of my head, there may be others.

like image 45
Sean Reilly Avatar answered Oct 02 '22 21:10

Sean Reilly