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

[Victor Williams Stafusa da Silva]

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?