• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java 5 and backward compatibility

 
Tom McAmmond
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

Comments from our Author, or anyone else?
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The coding developed using previous versions are surely be executed in the new version. However, you may not be able to use certain functions/APIs if you do not rewrite the codes.

You may see that some APIs are depreciated, but still, you can use it. That's the magic.

Nick
 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It makes sense to make java backward compatible. If not one has to migrate code developed for previous versions which is time consuming.
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think deprecated methods, constructors and so on in JDK 1.1 won't be in Tiger anymore...

Have you looked at the documentation at http://java.sun.com/j2se/1.5.0/docs/api/ ? Methods deprecated as long ago as 1.1 are still there. E.g. Thread's stop(), etc.

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.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Nick
 
somkiat puisungnoen
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can see detail of Java 2 Platform, Standard Edition Version 1.5.0 Compatibility with Previous Releases at


http://java.sun.com/j2se/1.5.0/compatibility.html


This will help you...


 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
[QB]I think deprecated methods, constructors and so on in JDK 1.1 won't be in Tiger anymore...

Have you looked at the documentation at http://java.sun.com/j2se/1.5.0/docs/api/ ? Methods deprecated as long ago as 1.1 are still there. E.g. Thread's stop(), etc.


Oh, yes it is still usable in Tiger!

Well, anyway, we need to avoid the use of deprecated methods in the real life as well as in SCJD assignment at least..
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In fact, SUN may find a cut-off version that remove those depreciated APIs.

I feel Mircosoft did this very strictly, but it makes developers know what they should do, instead of keep using the old style codes.

Nick
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nicholas Cheung:
I feel Mircosoft did this very strictly, but it makes developers know what they should do, instead of keep using the old style codes.
Nick


Only bad devlopers keep with the old "styles". Any half decent developer, when confronted with a depricated compiler warning, will find out what they need to do in its stead.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tom McAmmond:

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.
 
Mike Firkser
Ranch Hand
Posts: 249
Java Oracle PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Warren Dew:

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 ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic