19

It seems that the new java.time API offers everything from java.util.Date and much more.
Is there any reason to use java.util.Date when the newer java.time API is there since Java 8? Should java.util.Date and java.util.Calendar be avoided completely?

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
Ondrej Bozek
  • 10,987
  • 7
  • 54
  • 70
  • 5
    to support legacy code – pvpkiran Feb 08 '18 at 15:13
  • 3
    As I can remember, almost everything in `java.util.Date` is deprecated since JDK version 1.1, preferring `Calendar` since then – Sirmyself Feb 08 '18 at 15:16
  • They probably took what was good in `Calendar` and merged it with what was good in `Date` to allow programmers to have a tool as powerful as `Calendar` that is also as easy to use as `Date` – Sirmyself Feb 08 '18 at 15:21
  • 2
    Come on, what effort is done on research? You have 5k rep, you should be able to find out that such trivial question shows a clear lack of effort! Why even speak about `java.util.Date`? All of its business methods have been deprecated since Java 1.1. Do you really have to support an application that was mostly written between January 1996 (Java 1.0) and February 1997 (1.1)? – Olivier Grégoire Feb 08 '18 at 16:16
  • Related: [What's wrong with Java Date & Time API? [closed\]](https://stackoverflow.com/questions/1969442/whats-wrong-with-java-date-time-api) – Ole V.V. Feb 09 '18 at 10:22
  • 1
    @OlivierGrégoire Not that I defend the terrible class `java.util.Date` but the REAL business methods like `getTime()` or `after(Date)` or `before(Date)` are NOT deprecated and can be used without any warnings in the way they are designed for (`Date` is like an instant-type). I mention this fact for fairness. And legacy code can live very very long in production code simply because it can require too much effort or costs to migrate working old code. – Meno Hochschild Feb 09 '18 at 13:05
  • @MenoHochschild I explicitly spoke about the deprecation of **methods**, not the class itself. The class itself now serves more as a wrapper around a mutable `long` than anything else. Everything that isn't a basic wrapper around a `long` has been deprecated. – Olivier Grégoire Feb 09 '18 at 13:10
  • 1
    @OlivierGrégoire 1997? What are you talking about? Java 8 with replacement for `java.util.Date/Calendar` - `java.time` API was released around March 18, 2014. I.e in Hibernate, support for java 8 was implemented in version 5 released somewhere in the middle of 2016. Until than it was quiet common to use `java.util.Date` in entities. I didn't found mention that `java.util.Date` as such is deprecated and should be avoided. – Ondrej Bozek Feb 09 '18 at 13:11
  • 1
    @OndrejBozek Just read the [`java.util.Date` javadoc](https://docs.oracle.com/javase/8/docs/api/java/util/Date.html). It's full of `@Deprecated since JDK 1.1`. JDK 1.1 appeared in 1997. Also, I didn't say that `java.util.Date` is deprecated, but only that its date-business methods are since JDK 1.1, as refined by Meno's comment. – Olivier Grégoire Feb 09 '18 at 13:13
  • 2
    @OlivierGrégoire Yes, I have understood you when talking about deprecation of methods, but the most used, most important and real production business methods which I mentioned are NOT deprecated. Sure, `Date` is de facto like a thin wrapper around a long. People can completely ignore the deprecated stuff and `Date` still works as designed, namely as instant-like type. If anybody uses deprecated methods then he/she has done something very wrong. – Meno Hochschild Feb 09 '18 at 13:15
  • @OlivierGrégoire deprecated methods doesn't mean that the class is deprecated! `java.util.Date` was widely used until 1-2 years back. And probably is still used in huge majority of applications. I was speaking about whole class, not methods which are obviously deprecated from documentation. – Ondrej Bozek Feb 09 '18 at 13:16
  • 1
    @OndrejBozek I never said that `java.util.Date` is deprecated. it looks like I can't find the words to make myself clear: `java.util.Date` has been nothing but a basic wrapper since 1997. So you shouldn't have been using it for anything else than that, a wrapper, since then. – Olivier Grégoire Feb 09 '18 at 13:18

1 Answers1

24

Short answer: The new API java.time is way better than the old world with java.util.Date and java.util.Calendar. So yes, the new API should be preferred in new code.

For a quick overview: Once I had written a comparison of features in table form for various date-time-libraries. There is almost no feature which java.time is missing but exists in the old world:

  • configurable gregorian/julian cutover
  • printing based on the class FieldPosition (used in Swing-component FormattedTextField)

About deprecation: Although most parts of java.util.Date are deprecated since Java 1.1, the class itself (and java.util.Calendar, too) are not officially deprecated, just declared as de facto legacy. The support of the old classes is still important for the goal of backwards compatibility with legacy code. So Oracle will probably not stop the support at any time in the future. But maybe Oracle will apply more sophisticated deprecation strategies.

Future development: It is interesting that the release of Java-8 has not only incorporated a completely new date/time-API (java.time) but also seen some few enhancements to java.util.Calendar, for example Calendar.Builder or SHORT_STANDALONE etc. Well, I can only speculate but this also seems to indicate that Oracle is not willing to stop the support of the old API in the near future.

Meno Hochschild
  • 42,708
  • 7
  • 104
  • 126