aspose file tools*
The moose likes Java in General and the fly likes Java 5 and backward compatibility Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Java 5 and backward compatibility" Watch "Java 5 and backward compatibility" New topic
Author

Java 5 and backward compatibility

Tom McAmmond
Ranch Hand

Joined: Feb 16, 2004
Posts: 58
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

Joined: Nov 07, 2003
Posts: 4982
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


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

It makes sense to make java backward compatible. If not one has to migrate code developed for previous versions which is time consuming.


Groovy
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
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...


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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.


"I'm not back." - Bill Harding, Twister
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
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

Joined: Jul 04, 2003
Posts: 1312
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...




SCJA,SCJP,SCWCD,SCBCD,SCEA I
Java Developer, Thailand
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
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

Joined: Nov 07, 2003
Posts: 4982
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

Joined: Jul 11, 2001
Posts: 15299
    
    6

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.


GenRocket - Experts at Building Test Data
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
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

Joined: Oct 21, 2003
Posts: 247

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 ]

Mike Firkser
Rutgers '84
 
Consider Paul's rocket mass heater.
 
subject: Java 5 and backward compatibility