An informal survey from Devoxx says Java 8 or 9 should NOT be backwards compatible. I agree; people shouldn't be using old stuff, it's time to move on.

195 people said to remove old stuff to make room for the new. (Does the old stuff take THAT much room? How much room are we talking about?)

35 said some small incompatible changes would be good. As one who's been bitten by the "enum" keyword in the past, I think this is likely no matter what.

A whole 26 people said no, that backwards compatibility is essential to Java. Deduction says that 26 apache committers attended Devoxx.

4 people said they didn't care.

Look, java 5 is end-of-lifed; java 1.4 support is pointless. I'm at the point where a library that targets 1.4 just gets tossed from my toolbox. I don't use star wrenches neither, so there's no point.

It's time to say "Java will be backwards incompatible only so far, and some features simply aren't gonna be here when the next version comes up." java.util.Date comes to mind, with a fully-deprecated API, although if the JCP can't figure out how to import joda-time there might be issues.

In fact, if they can't figure out how to include joda-time, there ARE issues - how hard could this be? Anyone know what the delays are?

Anyway, what do you think should happen for backwards compatibility? Ever required it at the byte-code level?

The next version of Java is already not-backward-compatible. It is called Android.

I don't think backward compatibility is a great issue. If you can not upgrade your application, just use old Java. I completely agree, but there can be an issue: Old Libraries, which are not updated. That's the only problem, that must be fixed somehow..., I don't know how, maybe a bytecode transofrmer could be the answer.

Keep in mind that this type of transformation could be done by the JVM itself, at runtime, so we don't have to break backwards compatibility in order to avoid being hobbled by it ..

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

This is a very serious queation.  I worked in a government deparment where the deparment policies force all software development in Java be made with a Java compiler that is about 10 years old along with libraries that are 10 years old.   We all agree that ten years is a very long time in techonology.   I agree that newer versions don't require backward compatibility but all older versions of compiler and libraries be made available for a very long time (20 to 50 years).

The JVM is full of stuff that is deprecated since Java 1.1. Really have no clue why you should even add deprecation if all deprecated methods stay.

Deprecation should be used to give users of libraries / JVM ability to change their code, but its not neccesary to keep deprecated methods for ever.

E.g. if method is deprecated in JRE 1.3 release, it can be removed in Java 1.4 (or at least in 1.5 / 5.0).

Just my 2 cents.

I think backward compatibility should be removed in Java 8 or 9 onwards but with a fair degree to caution. I belive a good rule of thumb would be have the stuff available in the previous version that requires removal as deprecated in the present version and remove in the next version. Hence anything not required in Java 7 should be deprecated in Java 8 and removed completely in Java 9.

The future version of Java have a great improvement on GC and performance, I believe the company will invest to upgrade existing Java application.

backwards compatibilty has long been one of java's strong points, espcially in finanace and govermen sector which are slow to change, break them whould cause great havoc and woe.

but, look at what scala did, it provided closues, and other nifty things while still running on jvm, AND most important allows you the extend and interace with existing java classes..

isn't it possible to create a java3, a java syntax extending current java implemetation? it's there if you want it, but you don't have to dump your old code .

Look, java 5 is end-of-lifed; java 1.4 support is pointless. I'm at the point where a library that targets 1.4 just gets tossed from my toolbox.

And you're depriving yourself of some fine libraries that way for no good reason. Go read the Java forums on oracle.code and coderanch.com - plenty of people still run Java 1.4 and Java 5, and the problems they're having do rarely stem from using old JREs. Those versions are even supported through the "Java for Business" program, if someone thinks running obsolete versions is too risky otherwise.

oracle.code

That should read "oracle.com", obviously.

WE live in an age of progress, still why shouldn't we be able to use old stuff with new software. Why do we have to get rid of everything when something new appears?

<a href="http://www.adbriteledsigns.com/" title="led signs">LED Signs</a>

unfortunately there are lots of companies that are unable to move on to new versions of the JVM, and not because they do not want to, because some times the change involves a lot o money that no body is going to pay, or sometimes the system is working as smooth as they pretend, and migrating it will, for sure, cause problems.
In fact, I think backwards compatibility in JVM was guaranteed for 10 years. This gives a great advantage to any decision maker who needs to choose what language to adopt, compared with .NET for example, that in any mayor release, the things are totally different.

Backwards compability made sense some years ago, when software costs were high and the platform had to be stable,  but I think now backwards incompatibility may be  good news to Java programers.