I've heard many people say that Java's achilles heel is SUN's blind drive to make sure that Java is always backward/forward compatible. I've read a bit about Java 5 and it doesn't seem like they've given up on that yet, so one wonders if the improvements in performance and additions to the language have adequately compensated for its perceived weakness in backward compatibility. Answers will be purely subjective, by the very nature of the question, I realize
Originally posted by Pradeep Bhat: It makes sense to make java backward compatible.
How many versions back does Sun made a new JDK to be backward comapatible? What do u think the time that all the deprecated things are eliminated from the new JDK?
I think deprecated methods, constructors and so on in JDK 1.1 won't be in Tiger anymore... If we still use them, the Tiger would give us compilation errors, I guess... Correct me, if I am wrong... Thanks...
If we still use them, the Tiger would give us compilation errors, I guess...
Much like the javac compiler has all along, right?
I think it would be nice to eventually see a version of Java which abandons backwards compatibility with methods that have been bad ideas for five years or more. But don't expect it anytime soon - Sun is just now wrapping up the biggest set of changes in the language since its inception; I doubt they're going to want to immediately start making even greater changes in the next release.
"I'm not back." - Bill Harding, Twister
Joined: Nov 07, 2003
Seems that SUN just marked those APIs that should not be used as depreciated only. SUN has not removed those from latest release to make sure that systems written in old Java will still work even if we upgrade the JDK.
I've heard many people say that Java's achilles heel is SUN's blind drive to make sure that Java is always backward/forward compatible.
Gee, I've heard kind of the opposite - that Java's achilles heel is the tendency of the community process to add everything new including the kitchen sink into Java, whether it's a good idea or not.
Backward compatibility is important for preserving the sometimes very large investments made in legacy code that was written before the deprecation occurred. It may not matter to programmers who write such sloppy code that it will have to be rewritten in six months anyway, but for those who write code carefully so that it can continue to be useful for years and even decades, backward compatibility is critically important.
The fact is, deprecated aspects of the language are a tiny fraction of the total language - probably far smaller than new aspects that will never get much use. No one is forced to use them, so they don't do any harm, and they do a lot of good in preserving (and thus increasing) the value of the software we write.
Backward compatibility is important for preserving the sometimes very large investments made in legacy code that was written before the deprecation occurred.
That one line says it all - I would think long and hard about going to a new version of a language that requires me to go through all of my programs that have been running fine, but now may not work. By being backward compatable, it is possible to implement new technologies earlier. [ August 25, 2004: Message edited by: Mike Rutgers ]