1

In my Eclipse Android App I use type Date. I am warned that this is a deprecated type. Does this mean I cannot use it, or merely that it is bad practice to?

Thanks for the help!!

Alexis C.
  • 91,686
  • 21
  • 171
  • 177
Swedish Architect
  • 389
  • 3
  • 5
  • 23
  • 2
    Try it and you'll know. Hint: Yes you can, but should you? It's deprecated for a reason.. So you better know why. – Maroun Jan 08 '14 at 17:55
  • 2
    It means that it is bad practice to use it. It can still be used, but eventually it will not work with other things because it is no longer being supported. Best practice is to use the requested alternative to any depreciated type. It should do everything that the depreciated type does, just differently. The developers changed it for a reason. Usually because its structure will not work with something else such as a new type. – BobbyD17 Jan 08 '14 at 17:57

8 Answers8

11

Essentially deprecated is a warning to you as a developer that while the method/class/whatever is there and works it is not the best way to do it. Either a newer and better alternative is available or (sometimes) there is something subtly broken about it that makes it not advisable to use.

You can still use deprecated things - but you should look to see why they are deprecated first and see if the new way of doing things is better for you.

In theory deprecated things can or will in future be removed. That rarely happens (some Java libraries have deprecated stuff in them that is more than ten years old) but is a risk you should be aware of.

Tim B
  • 40,716
  • 16
  • 83
  • 128
  • The new way is better for date stuff, but I was cutting a corner, and not learning the new stuff, unless I actually needed to. :) Thanks – Swedish Architect Jan 08 '14 at 17:59
  • Don't rush to learn Calendar. Java 8 has a new time library coming that is supposed to be much better than Date or Calendar. – Tim B Jan 08 '14 at 18:00
  • 1
    deprecated says more than "there is a better way", it says: "it might stop working/be removed at any time in the future, without notice"... See for example `Thread#stop` which as been deprecated for some time: in Java 8, it throws an `UnsupportedOperationException`. – assylias Jan 08 '14 at 18:11
  • Yes. `Thread#stop` is a good example of "something subtly broken about it that makes it not advisable to use". It's interesting they finally removed it though - I didn't know that. It's about time tbh. – Tim B Jan 08 '14 at 18:21
  • 1
    @assylias I disagree with "without notice". I don't recall every having seen a deprecated function cease to function without notice. In my experience, there is usually a changelog or list of "breaking changes" included with the newer version which will document all such changes. If there isn't, it's either a drastically redesigned product, or a very unprofessional software release team. – Dan Bechard Jan 08 '14 at 18:41
  • 1
    @Dan Fair enough - that part was a bit exaggerated! ;-) – assylias Jan 08 '14 at 19:10
  • Correct but exaggerated. I'm gonna upvote you both now just because I agree with both of you :D – Tim B Jan 08 '14 at 19:11
  • 1
    @TimB For reference regarding Thread#stop: http://download.java.net/jdk8/docs/api/java/lang/Thread.html#stop-java.lang.Throwable- vs http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#stop%28java.lang.Throwable%29 – assylias Jan 08 '14 at 19:13
  • @assylias Thank you for providing the link. – Dan Bechard Jan 08 '14 at 19:17
5

Sure you can use it now, but it might be removed in the future. Better look for alternatives. You can also pack it into a library yourself, so you don't have to rely on the standard library.

tilpner
  • 4,351
  • 2
  • 22
  • 45
2

You can (we will not cut your hands, because we can't ;)), but it's a bad practice. They're always given newer substitutions, which you should use.

In the future deprecated functions can be removed, so your code can stop to work.

Adam Stelmaszczyk
  • 19,665
  • 4
  • 70
  • 110
2

If stopping to use the deprecated method doesn't break backward compatibility I prefer to move to new API, nothing is mandatory but the effort is so small that I prefer to have code without warnings

dafi
  • 3,492
  • 2
  • 28
  • 51
2

Old functions are sometimes retained alongside the newer functions designed to replace them for backwards compatibility. Such functions will often be marked "deprecated" to make this clear.

I disagree that it is always "bad practice" to use deprecated functions. If it were bad practice, they would not have been deprecated, the would have been removed. Existing code that makes use of deprecated functions is usually okay if left alone, but may require a refactor to make use of newer versions of a library.

It is important to point out that "deprecated" does not necessarily mean the function will cease to exist or work in a new version. It may remain working and part of the library for the lifetime of library.

It is, however, bad practice to use deprecated functions in new code. I have never seen a function marked "deprecated" without having been replaced with some newer, usually better, alternative. New code should make use of the updated function which will often contain important optimizations, design changes, or bug fixes.

Dan Bechard
  • 5,104
  • 3
  • 34
  • 51
1

The second: it's just considered BAD PRACTICE. But still working (in the NEAR future - for the FAR future it's not guaranteed working anymore).

You're discouraged to use it, but you can.

Phantômaxx
  • 37,901
  • 21
  • 84
  • 115
0

It depends on the reason why it was deprecated. Read javadocs. For example it makes no sense to use Thread.destroy

/**
 * Throws {@link NoSuchMethodError}.
 *
 * @deprecated This method was originally designed to destroy this
 *     thread without any cleanup. Any monitors it held would have
 *     remained locked. However, the method was never implemented.
 *     If if were to be implemented, it would be deadlock-prone in
 *     much the manner of {@link #suspend}. If the target thread held
 *     a lock protecting a critical system resource when it was
 *     destroyed, no thread could ever access this resource again.
 *     If another thread ever attempted to lock this resource, deadlock
 *     would result. Such deadlocks typically manifest themselves as
 *     "frozen" processes. For more information, see
 *     <a href="{@docRoot}/../technotes/guides/concurrency/threadPrimitiveDeprecation.html">
 *     Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?</a>.
 * @throws NoSuchMethodError always
 */
@Deprecated
public void destroy() {
    throw new NoSuchMethodError();
}
Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275
0

You can use it for now, but it may be completely discarded in the future. This means that someone would have to be using the JVM of the version of java that you made this with, which is unlikely. You should only use it if your users can get updates for your program.

user3170404
  • 13
  • 4