Skip to main content

How far back should Java retain backwards-compatibility?

Across minor releases (Java 1.6)
19% (108 votes)
5 years back (Java 1.5)
48% (271 votes)
10 years back (Java 1.3)
16% (89 votes)
As far back as possible (Java 1.1)
12% (69 votes)
I don't know
4% (20 votes)
1% (5 votes)
Total votes: 562


One idea about how to deprecate and remove old apis

This is how it works in netbeans. An api is marked for deprecation in major version A, it is visible to major version B and can be used in new code, in major version C the compiler hides the deprecated apis for new code and will not compile, however the platform will still run a library that was compiled against an older api, in major version D the api is removed but a 'compatibility layer? (for a lack of a better term)' can be downloaded from the update center to use legacy jars and apis and is discouraged from use. Would this be an adequate solution for this problem? I think so! This way all you people fear mongering 'WE NEED TOTAL COMPATIBILITY, FOR EVER' can just stop it and start updating your systems one by one this way. Or, just don't use a newer JDK and be stuck in Java 1.4 land for ever!

Infinite compatibility

I think compatibility should never break. Enterprises are conservative, one of Java's advantages is that Visibroker 3 from 1998 is still running on Java 1.6. Organisations are buying IBM mainframes because they still run software from the 1970ies. But the JRE could decide corresponding to the class version what compatibility is needed.

Yes, but...

I think it is worth noting that when (and if) IBM supports software dating back to 1970s they don't release new versions for it on a regular basis. You're running an "appliance" whose hardware and software are frozen in time. You're asking Sun to go above and beyond what anyone else (IBM included) has done. There are two solutions, as pointed out by "badapple": 1. Keep running Java 1.4 forever (equivalent to IBM's approach) 2. Use a "compatibility module" containing removed code. Though, to a certain degree, this is similar to option 1 because it can't be supported forever.

Do you mean language, VM, or library compatibility ?

The poll question is pretty vague. Are we talking about language, VM (ie. bytecode), or core library backward compatibility ?

A process for breaking compatibility is important

I live, for better or worse, deep in Enterprise-land, and backwards compatibility is a huge priority. A hypothetical example: If Java5 had broken compatibility, I would not have been able to upgrade--my investment in existing apps and would have been nullified to some extent and I would probably have stuck with 1.4 to finish then current projects.

However, time marches on, and hopefully the Java platform does too. We should not have to suffer under the poor design decisions of the past--it is time to deprecate certain APIs. I think it is reasonable to set a timeline for deprecating certain areas. But just as important as what to deprecate, and when, is the question of how.

It is important for there to be communication between the Java community and Sun/Oracle and the JCP about breaking compatibility, and establishing a precedent for how to do it. The Python community does this quite well, as deprecated apis at first show warnings in the first deprecated version, and then errors in the following version as they are removed.

Excellent suggestion!

1. Deprecate a feature in version 1.4, issue compile-time warnings if it's used
2. Issue compiler-time errors in version 1.5 (precompiled code still runs)
3. Remove the feature in version 1.6 (precompiled code no longer runs)

Deprecated should mean deprecated, and then gone...

Trying to maintain backward compatibility to the 'year dot' is a futile, expensive and ultimately pointless exercise. Just look at Microsoft Windows to see how trying to maintain backward compatibility for too long can hurt you. Two major versions is the most we should expect - so for example Java 7 could compile and run unmodified Java 5 code, but not Java 1.4 code if there is a good technical reason. Soften the blow by providing migration patterns.

The question doesn't make sense...

If you introduce a feature in version 1, and support it until version 100, and then remove it in version 101, then you've failed to support compatibility between two adjacent releases (100 and 101). How can you possibly preserve compatibility between every pair of adjacent releases and yet break compatibility between further releases?


Well clearly you can't both preserve and break compatibility if you remove features without warning. I've always believed that this what @deprecated is for - an indication to stop using something. Using your example I'd mark something as deprecated in release 101 and then remove it in release 102. Unfortunately this is unworkable for all practical purposes if the release cycle is long. You'd need a good crystal ball to have known what to deprecate in Java 'x' that would then be removed in Java 'x+1', the alternative being that you identify what you want to deprecate while developing Java 'x+1' but then can't remove it until version 'x+2' which in turn delays the nice new feature that relies on that deprecated code being removed. In short I think the degree with which you can get away with deprecating and then removing features depends on the frequency of release. This in turn cannot be too frequent (works against adoption) or too infrequent (works against innovation). Personally I think the most sensible way ahead would be to not guarantee compatibility between major releases (e.g. Java 6 to Java 7) but make them less frequent (say every 2-3 years) and to roll out more incremental releases with new features in them (6.1, 6.2 etc) on a more frequent basis - say every 6-9 months, allowing people to get backwards compatible updates with enhancements more quickly. Of course this may still be utterly impractical, not knowing the fine details of the development lifecycle in the JDK team.

Java will be 20 on this

Java will be 20 on this December and I agree that it needs to lose some excess baggage. I feel that cutting it in half (10 years) is reasonable.

Backwards compatibility is innovations biggest enemy!

Backwards compatibility, while important to some degree, needs a cutoff at some point. If you try to remain compatible for ever you will inevitably be working around bugs or bad design decisions from the past. Its time to let go people! Pre Java 5 should not be supported any more, they have had 5+ years to upgrade, what more do you want? Trying to remain compatible for ever, is like trying to support Windows 3 today, just let it go, its time to move on.