While a diverse range of views was expressed in comments posted to this past week's java.net poll, almost half of the voters considered five years to be the best duration for maintaining backward compatibility. This poll was submitted by java.net community member cowwoc (Gili Tzabari), and it was indeed a very successful poll: 562 votes were cast, and people took the time to post 11 comments.
Here's the exact question and results:
How far back should Java retain backwards-compatibility?
19% (108 votes) - Across minor releases (Java 1.6)
48% (271 votes) - 5 years back (Java 1.5)
16% (89 votes) - 10 years back (Java 1.3)
12% (69 votes) - As far back as possible (Java 1.1)
4% (20 votes) - I don't know
1% (5 votes) - Other
Backward compatibility is a very interesting problem when it comes to widely used languages that have an enormous installed base -- languages like Java, C/C++, COBOL, Fortran. In some cases, the languages have become "legacy languages" -- they have a big installed base, but very few people are actually developing new code in the languages any more. Fortran and COBOL are in this category, I think. There, you have lots of solid, completely tested, operational code that still needs to be used. It makes no sense to redevelop the applications, so typically the legacy code is just wrapped inside modern technology. The legacy code becomes an engine that is interfaced with, accessed, using modern technology. With such languages, you really would want any new editions of compilers (consider, for example, Fortran 95) to be completely backward compatible, so you don't break the working legacy applications.
Java is in a very different category. And herein lies the problem. You do have an enormous installed application base, and that code was built using many different versions of Java. In many cases, the original developers of this code are no longer working for the companies. Meanwhile, Java is also very actively used for developing new software applications today.
So, with Java, there is a tension when it comes to backward compatibility. On the one hand, you have a legacy-like installed base of old code, which argues for compete backward compatibility; but, for new development, the language needs to keep pace with the modern world, which means new language features are needed. To give just one example: how does Java respond to "the multicore challenge"?
The comments posted to the poll reflect this tension. weberjn advocates "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.
cowwoc responded with "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.
badapple said "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.
philistine takes the middle approach, noting that "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.
Thanks, Gili (cowwoc), for a great poll idea!
If you've got an idea for a poll, please send it to me -- one way you can do this is with the java.net Submit Content page. Or you can direct message me @kevin_farnham on Twitter. Or you can post a comment below. Etc., Etc... (there are lots of ways to contact me)...
Creating hyperlinks in JavaFX should be in the category of things that are trivially easy, but is complicated by various factors, such as deployment mode and Java version. First I will go into detail on all the different permutations of how you can launch links in a browser and under what circumstances each will work. Next I will give you a nice packaged solution that you can use as a library...
When I heard about first JavaFX challenge, I decided to participate with some application that can show how powerful this language is. In order to do that, I created my own version of Rubik’s Cube game. Now, after upgrading it to JavaFX 1.2 version, I wish to share it with you...
Introducing the new Asynchronous HTTP Client library, which allow applications to execute HTTP requests and asynchronously process the HTTP response. Read the official announcement here. Brian McCalister, Thomas Dudziak and I worked on that library since I've joinned NIng back in December. The library purpose is to allow Java applications to easily execute HTTP requests and asynchronously process the HTTP responses. You can get it at...
I just updated the Cejug-Classifieds Project to support Maven 2 builds and I added some new features, including a Shell Script able to configure the resources and also to deploy the the application in the Glassfish V3. The script creates all Java EE resources required by the application, like the DataSource, the JavaMail connection and the JMS Queues. In the next sections I will describe how to create each of this resources using the "Glassfish's Administration CLI tool" (the asadmin command line)...
How can you improve, harmonize and automate your development process using tools like Maven, Hudson, and Nexus? This presentation is a high-level overview of Java software development process improvement, aimed at explaining the concepts behind optimizing the SLDC to management and product owners...
In the Forums, Ronak Patel wonders about Glassfish on the Amazon Cloud: Hi All, I was wondering if others have successfully run Glassfish V2/V3 in the Amazon cloud before. Specifically, I'm wondering if there is some AMI that I can use to keep cloning instances of working Glassfish servers that can be...
In the JXTA forum, ezez85 has questions regarding multiple jxta socket connection using one pipe adv: Hi, i have questions that i like to clarify. I have create a listening thread to listen for any incoming connection by using one pipe adv. But i realized jxta will tear down any previous connection in order to create a new one. I would like to know is it...
In the Java SE Snapshots forum, gordan says Re: java.util.Collections still misses unmodifiableIterator(): A typical example is when a class wraps a collection and implements Iterable : /** Immutable class to provide informations about all installed applications. */ public final class ApplicationInfos implements...
We just published a new java.net Feature Article, Dibyendu Roy's Rethinking Multi-Threaded Design Principles; in the emerging multicore/multiprocessor world, multi-threaded programming is critical, in my view. We're also featuring Has JDBC Kept up with Enterprise Requirements? by Jesse Davis; in the article, Jesse invites us to look beyond Type 4 architecture to address the latest requirements of the enterprise Java ecosystem. And, Adhir Mehta's Java Tech article, Web Service Simulatino Using Servlets also remains in the Featured Articles section of the java.net home page.
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
