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

[Peter Lawrey]

Hi,
   The only way forward is to have code checkers, possibly built-in, to
suggest alternatives.
Getting novices to use them is also a challenge.

BTW This is an example of how hard it is to kill poor code. At one point, I
edited a few hundred copies of this block of code on StackOverflow, but
below is an example from 2022.
I assume the original author used DataInputStream.readLine() before
realising he should use BufferedReader. I found an example from 2002,
possibly the original.

A google search suggested there are about 3k copies of this code around.
https://www.google.com/search?q=%22Get+the+object+of+DataInputStream%22

FileInputStream fstream = new FileInputStream("D:adresse.txt");
// Get the object of DataInputStream
DataInputStream in = new DataInputStream(fstream);
BufferedReader br = new BufferedReader(new InputStreamReader(in));

Regards,
   Peter.

On Mon, 9 May 2022 at 20:44, Brian Goetz <brian.goetz at oracle.com> wrote:

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