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

[Ethan McCue]

> code checkers, possibly built-in

Maybe instead of tackling Date specifically lets ask "What would it look
like for the JDK to have a built-in fully featured linter."

The capabilities provided by javac's lints like -Xlint:deprecation are a
subset of the capabilities of a more fully featured linter like SonarCube.
There is no reason SonarCube's bottom line should be any of our concern, so
there isn't any conceptual reason the JDK couldn't include something akin
to clippy - "jlint"? - and have that be the place to really flesh out how
tooling should communicate the nuance / "best practices" around older apis.



On Mon, May 9, 2022 at 4:15 PM Peter Lawrey <peter.lawrey at gmail.com> wrote:

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