11

Do any problems arise because of using deprecated functions in Java?? If so, why do they keep this function?? Is it a bad habit if you use a deprecated method in Java like java.sql.Date.getMonth or getYear or getDate???

Saher Ahwal
  • 9,015
  • 32
  • 84
  • 152
  • Related: Herb Sutter's article, ["Interrupt Politely,"](http://www.drdobbs.com/architecture-and-design/207100682) from his series on Effective Concurrency. – James McNellis Aug 09 '10 at 00:55
  • you should read http://stackoverflow.com/questions/2941900/is-it-wrong-to-use-deprecated-methods-or-classes-in-java – Umesh Aawte Aug 16 '10 at 10:31

6 Answers6

10

Some potential problems are:

  • Methods may cease to exist (this has never been the case in practice, but by the official definition, deprecated methods may be eliminated from future Java)
  • Serious programming errors may occur due to fatal flaws in deprecated methods (e.g. System.runFinalizersOnExit and its evil twin Runtime.runFinalizersOnExit)
  • Data corruption can occur due to inherently unsafe deprecated methods (e.g. Thread.stop)

References

Related questions

Community
  • 1
  • 1
polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
  • See also "Why Are `Thread.stop`, `Thread.suspend`, `Thread.resume` and `Runtime.runFinalizersOnExit` deprecated?" http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html – polygenelubricants Aug 08 '10 at 19:22
  • but How do I use, for example, Calendar.get(Calendar.MONTH) instead of Date.getMonth()?? I get a java.sql.Date from the database and I need to get it's month... – Saher Ahwal Aug 08 '10 at 19:27
  • 1
    Date.getMonth() is save to use, you just have to get used to the fact that 0=January, 11=December, which is a bit counter-intuitive. Since java.sql.Date depends on java.util.Date, java.util.Date will not go away. I guess it's deprecated because it is a bad API and not compatible with "exotic" calendars. – Erich Kitzmueller Aug 08 '10 at 19:32
  • Of the 3 items in your list, only 1 of them is a real actual problem (the first one). The other 2 are not problems as much as they are "bypassable protections". – djangofan Feb 20 '14 at 19:46
3

No methods have actually been removed yet so existing code will keep running. Sun has been very focused on backward compatability.

The primary benefit is to move away from code that for some reason has been found to work suboptimallly, and usually there is a replacement elsewhere in the runtime library. Hence it is a bad habit to use them, and you should take heed and use the recommended replacements whenever the compiler flags a deprecation. It is generally a good idea to aim to eliminate compiler warnings.

You can see a list of what is deprecated in the Javadocs. The Java 5 list is at http://download.oracle.com/javase/1.5.0/docs/api/deprecated-list.html

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
2

Deprecated methods are kept so that code written for a previous version of Java still functions. If they just removed the code then previously functioning code would stop working when you updated Java to a new release.

Using deprecated functions will not cause you any problems beyond that which caused the method to be deprecated. However, it is best to find out what has replaced the deprecated method. The deprecated functionality will have been replaced with new functionality possibly found in a new class. Much of the deprecated Date functionality has been moved to Calendar. Check the Javadoc for the to see the recommended replacement.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
BillThor
  • 7,306
  • 1
  • 26
  • 19
1

The code may break in the future...

deprecated functions are a warning that this function will go away.

Look for alternative ways to fix the problem now, or you will have the code break in the future.

George Lambert
  • 616
  • 3
  • 4
1

A deprecated class or method might get removed in a future version. Sun had the habit of deprecating stuff and never actually removing it which in my opinion is not so good because it makes it seem Ok to use deprecated methods. Still you should not use deprecated methods where possible (and it should always be possible). This goes especially for external libraries which imho generally are not as afraid as Sun to remove deprecated code.

musiKk
  • 14,751
  • 4
  • 55
  • 82
  • 1
    It is good that SUN/Oracle haven't remove any deprecated method, it is up to you if you keep programming new apps with those deprecated methods. But there are some old utilities, apps or whatever that some of us and companies are using since 2002 for example... and there is no need to change the code of that app... – Garis M Suero Aug 08 '10 at 19:19
  • I think that's wrong and it doesn't have to be like that. Take Perl as an example. It's age-old and a huge quantity of programs are written in it but still stuff gets deprecated in one version and removed without a trace in the next. – musiKk Aug 09 '10 at 07:27
  • Tell that to the thousands of companies that have legacy apps whose livelihood depends on them running. Yes, for you it seems wrong, but look at it from other's point of view. It's a no-brainer to keep the deprecated functions – Henley Apr 26 '11 at 16:00
1

As others have pointed out, Sun has never removed any deprecated methods from the JDK, but the same is not true with deprecated methods in third-party libraries. Those do disappear sometimes (the Lucene project for example has a rather "fluid" API here, doing major cleanups with major versionups).

Even in the JDK, the method being deprecated means that "there is a better way to do this now", and you should probably update your code to use the new version.

It is very rare that the deprecated method does not work correctly for what it was originally intended to do, but the replacement will usually work more reliable, or in more circumstances, or in a more general way. Good examples here are the Date functions that you mention (deprecated because they do not work well with different locales/calendars), or String-to-byte conversions that only work with 7-bit-ASCII. These caveats/restrictions cannot be fixed without a new interface, or because someone may depend on the "broken" implementation, so instead of updating the method, they deprecate it and provide an alternative one.

Thilo
  • 257,207
  • 101
  • 511
  • 656