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

[Ethan McCue]

To play devil's advocate here

1. I'll assert without proof that in general people are very sensitive to
new warnings. If you upgrade your app 22 -> 23 and suddenly you get a bunch
of depreciation warnings that would hold back adoption in the ecosystem in
a small but significant way

2. Deprecation isn't really the "right" concept. Date isn't an "unsupported
path", and calling .toInstant on it and the reverse would be the supported
way of working with the myriad apis that take and return Dates. My first
stab at describing the situation would be something like
@Prefer(Instant.class)

On Sun, May 8, 2022, 8:28 AM Peter Lawrey <peter.lawrey at gmail.com> wrote:

> Hi
>   I would add that a JSR 310 backport is available for Java 6 & 7. So even
> those needing to support 6 can drop use of these classes.
>
> https://www.threeten.org/threetenbp/
>
> Regards Peter
>
> On Sun, 8 May 2022, 03:43 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?
> >
>