160

I am using eclipse to develop a web application. Just today I have updated my struts version by changing the JAR file. I am getting warnings at some places that methods are deprecated, but the code is working fine.

I want to know some things

  1. Is it wrong to use Deprecated methods or classes in Java?

  2. What if I don't change any method and run my application with warnings that I have, will it create any performance issue.

aioobe
  • 413,195
  • 112
  • 811
  • 826
Umesh Aawte
  • 4,590
  • 7
  • 41
  • 51
  • 8
    Would you 'continue' to drive your `1955 Volkswagen Beetle` even if you are offered `Corvette Stingray`, for free? (0: – KMån May 31 '10 at 07:12
  • 81
    @KMan you are comparing a European car to an American car?;) – ponzao May 31 '10 at 07:17
  • 2
    @Ponzao and `4` others: Gotcha! (0; – KMån May 31 '10 at 07:41
  • 2
    Wrong? Are we talking mortal or just venial deprication here? – FastAl Aug 23 '10 at 17:39
  • 5
    @Alexander no votes for your comment, so +1 for yours too ;) in any case, hardy that the new code is 1000 better then the old code. The comparison would be better between `1955 Volkswagen Beetle` and `1956 Volkswagen Beetle` with new tires that you don't know when will break! – Aleks Apr 07 '14 at 12:26
  • I recently moved from Lucene 3.6 to 5.3.0. Some methods and classes have been deprecated. I dont get the same success when using these deprecated methods. –  Sep 23 '15 at 13:19

15 Answers15

275

1. Is it wrong to use Deprecated methods or classes in Java?

From the definition of deprecated:

A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.

The method is kept in the API for backward compatibility for an unspecified period of time, and may in future releases be removed. That is, no, it's not wrong, but there is a better way of doing it, which is more robust against API changes.

2. What if I don't change any method and run my application with warnings that I have, will it create any performance issue.

Most likely no. It will continue to work as before the deprecation. The contract of the API method will not change. If some internal data structure changes in favor of a new, better method, there could be a performance impact, but it's quite unlikely.


The funniest deprecation in the Java API, is imo, the FontMetrics.getMaxDecent. Reason for deprecation: Spelling error.

Deprecated. As of JDK version 1.1.1, replaced by getMaxDescent().

Drupad Panchal
  • 383
  • 3
  • 10
aioobe
  • 413,195
  • 112
  • 811
  • 826
  • 7
    Next funniest deprecation in Java API would be setMultiClickThreshhold(int threshhold) and getMultiClickTreshhold() in AbstractButton (Swing). Get ready for those two! ;) – JavaTechnical Jul 09 '13 at 17:25
  • 3
    We need to do this with HTTP REFERER. It's maddening: https://en.wikipedia.org/wiki/HTTP_referer – kmiklas Jan 19 '17 at 00:21
  • 1
    @DaveMcClelland , made it 70 from 69 :D ;) – VedantK Apr 21 '17 at 08:35
30

You can still use deprecated code without performance being changed, but the whole point of deprecating a method/class is to let users know there's now a better way of using it, and that in a future release the deprecated code is likely to be removed.

abyx
  • 69,862
  • 18
  • 95
  • 117
  • 2
    How can you be sure that it's without change in performance? The deprication *could* for instance be due to a change of an internal data structure, say from a HashSet to a TreeSet, for instance. – aioobe Aug 21 '10 at 20:51
  • @aioobe - To my understanding, the OP asked whether calling deprecated code has any performance issues, which it doesn't given that it doesn't change produced byte code (prior to 1.5 was in javadoc, now the annotation is in use, but still no change to performance) – abyx Aug 21 '10 at 21:09
  • When going from one version of a library, to another, there is no guarantee that the byte code of a method in the new version is identical to the byte code of the same method in the previous version. – aioobe Aug 21 '10 at 21:40
  • @aioobe - there is a guarantee that simply making it deprecated won't change byte code, which is what I think the OP meant. Of course code itself changes, which is why we deprecate code. – abyx Aug 22 '10 at 05:08
  • 1
    If you keep using the same version as before, there is no change. But if you user a newer version of the library, and they have no deprecated the API, there COULD be an alteration in performance, if the underlying implementation is drastically altered and the new API takes advantage of it, while the older API is not as efficient as it used to be, against this newer structure. – gregturn Oct 05 '17 at 15:52
21

Terminology

From the official Sun glossary:

deprecation: Refers to a class, interface, constructor, method or field that is no longer recommended, and may cease to exist in a future version.

From the how-and-when to deprecate guide:

You may have heard the term, "self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.

The @Deprecated annotation went a step further and warn of danger:

A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.

References


Right or wrong?

The question of whether it's right or wrong to use deprecated methods will have to be examined on individual basis. Here are ALL the quotes where the word "deprecated" appears in Effective Java 2nd Edition:

Item 7: Avoid finalizers: The only methods that claim to guarantee finalization are System.runFinalizersOnExit and its evil twin Runtime.runFinalizersOnExit. These methods are fatally flawed and have been deprecated.

Item 66: Synchronize access to shared mutable data: The libraries provide the Thread.stop method, but this method was deprecated long ago because it's inherently unsafe -- its use can result in data corruption.

Item 70: Document thread safety: The System.runFinalizersOnExit method is thread-hostile and has been deprecated.

Item 73: Avoid thread groups: They allow you to apply certain Thread primitives to a bunch of threads at once. Several of these primitives have been deprecated, and the remainder are infrequently used. [...] thread groups are obsolete.

So at least with all of the above methods, it's clearly wrong to use them, at least according to Josh Bloch.

With other methods, you'd have to consider the issues individually, and understand WHY they were deprecated, but generally speaking, when the decision to deprecate is justified, it will tend to lean toward wrong than right to continue using them.

Related questions

Community
  • 1
  • 1
polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
  • 3
    "Deprecated" is from the Latin "de"+"precare" meaning "to pray against". When something is described as deprecated a Standard is praying -- begging -- you not to use it; it's a warning that it may be removed in a future version of that Standard. Note that a deprecated feature is required to be fully implemented in any implementation of the current version of that Standard. Your mention of self-deprecating humour is slightly off-the-mark, though; "self-deprecating" in that sense is a corruption of "self-depreciating", which has a different derivation and meaning. – dajames Feb 09 '17 at 08:24
17

Aside from all the excellent responses above I found there is another reason to remove deprecated API calls.

Be researching why a call is deprecated I often find myself learning interesting things about the Java/the API/the Framework. There is often a good reason why a method is being deprecated and understanding these reasons leads to deeper insights.

So from a learning/growing perspective, it is also a worthwhile effort

Peter Tillemans
  • 34,983
  • 11
  • 83
  • 114
11

It certainly doesn't create a performance issue -- deprecated means in the future it's likely that function won't be part of the library anymore, so you should avoid using it in new code and change your old code to stop using it, so you don't run into problems one day when you upgrade struts and find that function is no longer present

Michael Mrozek
  • 169,610
  • 28
  • 168
  • 175
  • 1
    Judging from experience, "deprecated" really means "you shouldn't use this any more, but it will be available for ever and ever." At least for the Java Standard API, I am not aware of any method or class ever actually being removed after being deprecated. – Michael Borgwardt May 31 '10 at 07:13
  • 1
    @Michael Well, in practice APIs rarely remove deprecated functions because they could be deprecated for ten years with compilers outputting "WARNING: STOP USING THIS YOU FOOL", and people would still flip out the day they finally removed it. I think deprecated is supposed to mean "someday we want to take this out, so please stop using it", even if in practice it rarely actually happens – Michael Mrozek May 31 '10 at 07:24
  • @Michael Mrozek: Disagree with the statement `It certainly doesn't create a performance issue`; its too subjective to state that. – KMån May 31 '10 at 07:44
  • 1
    @KMan A function being marked as deprecated doesn't somehow make it less efficient then it was before being marked -- it will run exactly the same as before – Michael Mrozek May 31 '10 at 17:09
  • @Michael Borgwardt: That's how it works in most standardized languages. And, of course, if anything deprecated was to be removed from the standard, popular implementations would keep it as an extension. – David Thornley Aug 05 '10 at 14:06
  • @David You replied to me, not Borgwardt. I'm not sure there is a way to reply to him, unfortunately (see [bullets 4 and 5](http://meta.stackexchange.com/questions/11098/reply-to-comment-feature-request/35918#35918)) – Michael Mrozek Aug 05 '10 at 15:11
  • Now that's an idea...if they make the deprecated method perform slowly, and progressively more and more so which each version then eventually people will stop using it. At some point there will be too few uses left and it can be removed from the API. – Miserable Variable Aug 23 '10 at 18:25
  • Do deprecated methods actually get deleted from the standard Java APIs? Any examples? – CodeClimber Aug 26 '10 at 14:55
8

It's not wrong, it's just not recommended. It generally means that at this point there is a better way of doing things and you'd do good if you use the new improved way. Some deprecated stuff are really dangerous and should be avoided altogether. The new way can yield better performance than the deprecated one, but it's not always the case.

Bozhidar Batsov
  • 55,802
  • 13
  • 100
  • 117
8

You may have heard the term, "self-deprecating humor". That is humor that minimizes your importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that it should no longer be used at all, as it will probably cease to exist in the future.

Try to avoid it

jmj
  • 237,923
  • 42
  • 401
  • 438
4
  1. Generally no, it's not absolutely wrong to use deprecated methods as long as you have a good contingency plan to avoid any problems if/when those methods disappear from the library you're using. With Java API itself this never happens but with just about anything else it means that it's going to be removed. If you specifically plan not to upgrade (although you most likely should in the long run) your software's supporting libraries then there's no problem in using deprecated methods.
  2. No.
Esko
  • 29,022
  • 11
  • 55
  • 82
3

Yes, it is wrong.

Deprecated methods or classes will be removed in future versions of Java and should not be used. In each case, there should be an alternative available. Use that.

There are a couple of cases when you have to use a deprecated class or method in order to meet a project goal. In this case, you really have no choice but to use it. Future versions of Java may break that code, but if it's a requirement you have to live with that. It probably isn't the first time you had to do something wrong in order to meet a project requirement, and it certainly won't be the last.

When you upgrade to a new version of Java or some other library, sometimes a method or a class you were using becomes deprecated. Deprecated methods are not supported, but shouldn't produce unexpected results. That doesn't mean that they won't, though, so switch your code ASAP.

The deprecation process is there to make sure that authors have enough time to change their code over from an old API to a new API. Make use of this time. Change your code over ASAP.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Erick Robertson
  • 32,125
  • 13
  • 69
  • 98
2

It is not wrong, but some of the deprecated methods are removed in the future versions of the software, so you will possibly end up with not working code.

Petar Minchev
  • 46,889
  • 11
  • 103
  • 119
  • `Removed`? See definition http://stackoverflow.com/questions/2941900/is-it-wrong-to-use-deprecated-methods-or-classes-in-java/2941912#2941912 – KMån May 31 '10 at 07:47
  • 1
    @KMan - in the link you posted it is written - "The method is kept in the API for backward compatibility for an unspecified period of time, and may in future releases be REMOVED." I have written the same - some of the deprecated methods are possibly removed in the near or far future. – Petar Minchev May 31 '10 at 08:26
2

Is it wrong to use Deprecated methods or classes in Java?"

Not wrong as such but it can save you some trouble. Here is an example where it's strongly discouraged to use a deprecated method:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Why is Thread.stop deprecated?

Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.


What if don't change any method and run my application with warnings that I have, will it create any performance issue.

There should be no issues in terms of performance. The standard API is designed to respect some backward compatibility so applications can be gradually adapted to newer versions of Java.

James P.
  • 19,313
  • 27
  • 97
  • 155
2

Is it wrong to use Deprecated methods or classes in Java? It is not "wrong", still working but avoid it as much as possible.

Suppose there is a security vulnerability associated with a method and the developers determine that it is a design flaw. So they may decide to deprecate the method and introduce the new way.

So if you still use the old method, you have a threat. So be aware of the reason to the deprecation and check whether how it affects to you.

what if don't change any method and run my application with warnings that I have, will it create any performance issue.

If the deprecation is due to a performance issue, then you will suffer from a performance issue, otherwise there is no reason to have such a problem. Again would like to point out, be aware of the reason to deprecation.

Chathuranga Chandrasekara
  • 20,548
  • 30
  • 97
  • 138
2

In Java it's @Deprecated, in C# it's [Obsolete].

I think I prefer C#'s terminology. It just means it's obsolete. You can still use it if you want to, but there's probably a better way.

It's like using Windows 3.1 instead of Windows 7 if you believe that Windows 3.1 is obsolete. You can still use it, but there's probably better features in a future version, plus the future versions will probably be supported - the obsolete one won't be.

Same for Java's @Deprecated - you can still use the method, but at your own risk - in future, it might have better alternatives, and might not even be supported.

If you are using code that is deprecated, it's usually fine, as long as you don't have to upgrade to a newer API - the deprecated code might not exist there. I suggest if you see something that is using deprecated code, to update to use the newer alternatives (this is usually pointed out on the annotation or in a Javadoc deprecated comment).

Edit: And as pointed out by Michael, if the reason for deprecation is due to a flaw in the functionality (or because the functionality should not even exist), then obviously, one shouldn't use the deprecated code.

jamiebarrow
  • 2,473
  • 3
  • 30
  • 51
  • 1
    "If you are using code that is deprecated, it's fine, as long as you don't have to upgrade to a newer API" - not quite. Look at why Thread.stop() is deprecated, and you'll see that it is not fine, in any JRE version. – Michael Aug 27 '10 at 09:52
  • Ok, I should rather say "usually" fine (will update that bit) :) Hence, use at your own risk. Obviously, if the reason for deprecating it is to stop a flaw in its functionality, it makes sense to not use it. In general though, it's fine to use a deprecated method. So ja, it all depends on the reason for deprecation. True. – jamiebarrow Aug 30 '10 at 10:22
1

Of course not - since the whole Java is getting @Deprecated :-) you can feel free to use them for as long as Java lasts. Not going to notice any diff anyway, unless it's something really broken. Meaning - have to read about it and then decide.

In .Net however, when something is declared [Obsolete], go and read about it immediately even if you never used it before - you have about 50% chance that it's more efficient and/or easier to use than replacement :-))

So in general, it can be quite beneficial to be techno-conservative these days, but you have to do your reading chore first.

ZXX
  • 4,684
  • 27
  • 35
1

I feel that deprecated method means; there is an alternate=ive method available which is better in all aspects than existing method. Better to use the good method than existing old method. For backward compatibility, old methods are left as deprecated.

David Glickman
  • 713
  • 1
  • 11
  • 18
DPM
  • 11
  • 2