Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses

Peter Lawrey peter.lawrey at
Sun May 8 07:25:44 UTC 2022

  I would add that a JSR 310 backport is available for Java 6 & 7. So even
those needing to support 6 can drop use of these classes.

Regards Peter

On Sun, 8 May 2022, 03:43 Victor Williams Stafusa da Silva, <
victorwssilva at> wrote:

> The java.time package was released in Java 8, far back in 2014, more than 8
> years ago. It has been a long time since then. Before that, we had the
> dreadful infamous java.util.Date, java.util.Calendar,
> java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time,
> java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat
> and a few other lesser-known obscure cases.
> There are plenty of reasons to avoid using Date, Calendar, DateFormat and
> their subclasses, otherwise there would be few to no reasons for java.time
> to be conceived.
> Applications and libraries which used or relied on those legacy classes
> already had plenty of time to move on and provide java.time.* alternatives.
> No skilled java programmer uses the legacy classes in new applications
> except when integrating with legacy APIs.
> Using those classes nowadays should be considered at least a bad
> programming practice, if not something worse (source of bugs, security
> issues, etc).
> Novices, unskilled, careless and lazy programmers who should know better
> still happily continue to use the legacy classes, pissing off those who are
> more enlightened.
> So, my proposal is pretty simple: It is time to put a @Deprecated in all of
> those (not for removal, though).
> First, let's deprecate all of them. Second, any method in the JDK returning
> or receiving any of those as a parameter should be equally deprecated. If
> there is no replacement method using the relevant classes or interfaces in
> the java.time package, one should be created (which is something probably
> pretty straightforward).
> If any of those methods is abstract or is part of an interface, then we
> have a small problem, and it should be solved on a case-by-case analysis,
> preferentially by providing a default implementation. I'm sure that some
> cases should still exist, but I doubt that any of them would be a
> showstopper.
> The negative impact is expected to be very small. Popular products like
> Spring and Jakarta either already moved on and provided java.time.*
> alternatives to their APIs or could do that quickly and easily. Anyone who
> is left behind, would only get some [deserved] deprecation warnings.
> On the positive impact side, more than just discouraging the usage of the
> ugly and annoying API of Date, Calendar and DateFormat for people who
> should know better, those classes are a frequent source of bugs that are
> hard do track and to debug due to their mutability and thread unsafety.
> Thus, we are already way past the time to make the compiler give a warning
> to anyone still using them.
> What do you think?

More information about the discuss mailing list