tags:

views:

164

answers:

4

Our project application uses Java 5 and now when I update Java 6, there are some kind of inconsistency with functionality and seeing this effects our manager passed comment that "Java is platform independent but version dependent", Is it really true ?

+3  A: 

New versions of Java will run code compiled in previous versions. So if you compile your code in Java 5 and then try to run it in a Java 6 environment it will run.

If you compile in Java 6 though it will not run in a Java 5 environment.

Vincent Ramdhanie
This isn't necessary true. There are pieces of code in 1.5 that won't compile in 1.6. I'm not sure if this is an Eclipse-compiler issue, however with 1.5, it allowed you to place @Override annotations on interface implementations. In fact, Eclipse would add these by default. In 1.6, this is a compiler error since it doesn't make sense logically. But realistically, this is nit-picking.For the most part, this is right. :P
Malaxeur
He's not talking about compiling 5 code with a 6 compiler. He's talking about running already-compiled 5 code in a 6 runtime.
Tom
This is not absolutely true. Even if they are minor, there are binary-incompatibilities between versions. See http://java.sun.com/javase/6/webnotes/compatibility.html#incompatibilities for upwards incompatibilities between Java 5 and Java 6.
Pascal Thivent
@Tom. Read the OP's first comment. She talks about the **build** failing.
Stephen C
@Malaxeur: The issue with @Override is the other way around: Java 6 code won't compile under Java 5 because the Java 5 compiler complains about the @Override annotations. It is not a compiler issue per-se. Sun's Java compiler / language folks quietly "corrected" the semantics of @Override.
Stephen C
A: 

Any time you upgrade any framework there may be some unforeseen changes, which is why unit tests are important, as you can then run your tests and ensure that the behavior hasn't changed.

There is nothing that states JDK6 will function as JDK5 did at all times. For example, it appears that the ordering in a HashMap will differ between the two versions, but, since a HashMap is unordered, that isn't a real problem, unless you expect the order to be consistent.

James Black
+1  A: 

According to Java SE Compatibility at a Glance:

The Java Platform, Standard Edition(Java SE) is strongly compatible with previous versions of the Java platform. Each version of Java SE has upwards binary-compatibility with the previous version, except for the incompatibilities noted in the documentation. Java SE does not support downward source compatibility, however: If source files use new language features or Java SE platform APIs, they will not be usable with an earlier version of the Java platform.

The documentation describes any compatibility issues between the current version and the version immediately preceding it.

So, as written, each version of Java SE has upwards binary-compatibility with the previous version, except for the listed incompatibilities (which are considered as minor). That said, no one forces you to upgrade (as long as support is not an issue). If you don't want to benefit from the new features of a new version (like performance improvements, API improvements, etc), don't do it. But in my opinion, the benefits are in general worth the (minor) efforts. Check yourself.

Pascal Thivent
A: 

Occasionally, new versions of Java introduce new Java features. However, maintaining backwards compatibility for all time is notoriously hard, and code written for newer versions of Java can not be expected to work with older versions of the run-time environment.

foxostro