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

Brian Goetz brian.goetz at oracle.com
Mon May 9 19:43:00 UTC 2022


The problem with such a proposal is that applications are not the only 
user of Date. Libraries -- including the JDK -- have baked Date into 
their APIs.

A simple example is java.security.Timestamp::getTimestamp, which returns 
a Date.  This one is easier because it is a final class, and could 
acquire a getTimestampAsLocalDate method, and deprecate getTimestamp.  
But even this gives a hint of the pain users are in for; the good name 
is taken, and since we don't overload on return types, we'd have to pick 
a lesser name.  And users would forever be confronted with the choice of 
the less desirable but better-named getTimestamp, and the more desirable 
but worse-named getTimestampAsLocalDate.

A more difficult example is java.security.cert.X509Certificate, with:

     public abstract Date getNotAfter();

This is a public abstract method in a public abstract class. This means 
that remediating this use is even more difficult.  We can add a default 
method that returns LocalDate that converts from Date, and then update 
existing implementations to swap what they view their canonical 
representation as, but there's still going to be an abstract method 
returning Date, that new implementations will be confronted with.  So it 
will be pretty weird to have an abstract method in a public abstract 
class / interface that returns a deprecated type.

And, after all this, I still don't see a path to removing it in the next 
10 years.  So this seems like a lot of contortion and rewriting and 
putting users in confusion positions for mostly symbolic benefit.

> 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.

As I hope you now see, you're ignoring a whole category of 
not-at-all-small impact.


On 5/7/2022 10: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?


More information about the discuss mailing list