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

[Stuart Marks]

You're definitely on to something in that java.util.Date is obsolete, or 
obsolescent, and perhaps conceptually at least it should be deprecated. If I were 
reviewing some code that used Date I'd certainly flag the issue. The main difficulty 
is that its usage is entrenched in implementation code, but more importantly, in APIs.

In another message you listed several dozen places in the JDK that use Date and 
related APIs. It would be certain amount of work to introduce replacements that use 
newer APIs and to suppress the warnings resulting from the existing APIs. This is a 
bunch of work, but it's not intractable. However, the benefits aren't very high, and 
so the priority is low.

That's just the JDK. What also needs to be considered is the amount of code out 
there that *uses* these APIs. Most of the usages are in legacy code, which people 
are unlikely to want to spend a large effort on migrating. In addition, Date and 
friends are used in third party library *APIs*, which have their own users. There's 
a lot of this code.

There are a few possible responses maintainers of this code can take when new 
deprecations appear.

  - Ignoring them. OK, if people ignore deprecation, then it doesn't really matter 
what we do.

  - Disable deprecation warnings. If people had warnings enabled, they presumably 
found value in having those warnings. Mostly this is useful for preventing new code 
from using deprecated APIs. If a lot of many not-very-useful warnings suddenly 
appear, people might disable warnings entirely, and thus miss the warnings they'd 
actually find useful. This defeats the purpose of having the warnings.

  - Migrate code to use other APIs. Some people will do this, if they're in a 
position to do so. Maintainers of legacy code generally are not able to do this. 
Library maintainers are also often not in a position to do this, as they have their 
own compatibility concerns.

  - Suppress warnings at the call sites using @SuppressWarnings. This is probably 
the most common alternative to code migration. This isn't a terrible option, but 
it's tedious, low-value work, and people don't like being forced to do work that 
isn't providing value to them.

This last point may be more significant than you think. When I deprecated 
java.util.Observer/Observable in Java 9, there was very little usage of these 
classes; yet I received a bunch of complaints from people having to deal with the 
warnings. Date and related classes have several orders of magnitude more usage. The 
number of warnings generated will be huge, and the effort required to deal with them 
will be tremendous.

By the way, all this also applies to other obsolescent but widely used classes such 
as Vector, Hashtable, LinkedList, URL, etc.

So if warnings are a problem, then maybe we should do something about that? That's a 
possibility. Some better form of @SuppressWarnings might be helpful. More flexible 
control over what warnings javac emits might be useful too.

(Somebody will inevitably suggest a different annotation that doesn't generate 
warnings. That would be incorrect, because the policy of how to handle usage of 
deprecated APIs, and whether warnings should be emitted, should be in the hands of 
the maintainers of the code that uses those APIs, not the API designers.)

s'marks



On 5/7/22 7:36 PM, Victor Williams Stafusa da Silva 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?
>