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

[Ron Pressler]

I think the issue is that "deprecated" means different things to different
people, and, to be fair, its meaning has shifted over the years. For some
developers it means "strongly unrecommended; do not use in new code." But for
the JDK developers it means, "dangerous to leave in; remove even from old
code". We now deprecate things:

1. whose use is so egregious that it can reasonably be treated as an error
(and many people treat compiler warnings as errors), and/or

2. that could reasonably be removed at some point in the future.

Date doesn't satisfy either one of these conditions.

So to "strongly unrecommend" Date in some mechanical way would probably require
a new kind of annotation that means what the first group I mentioned means, and
possibly a new kind of compiler warning that shouldn't be treated as an error.

— Ron


> On 8 May 2022, at 03:36, Victor Williams Stafusa da Silva <victorwssilva at gmail.com> 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?