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

[Anderson Vasconcelos Pires]

Ok... Is not beneficial to deprecate these classes but I believe should be
considered the points mentioned by Stephen Colebourne in his email,
specially the point 1 shown below not just because of the better code
design but for performance reasons. I guess! :)

1) there is no alternative in certain cases for those who wish
to completely avoid the old classes".

If we can use the java.time classes directly, it is better for performance
reasons than creating an intermediate instance of the obsolete classes
to get the desired class, right?

Imagine the situation where we have to read a lot of data from the database
and we need to use Instant class. I understand it would be pretty good to
have the usage of it directly in the interface java.sql.ResultSet to avoid
unnecessary instance creation of Timestamp class, right?

Can/will the JIT optimize this task by passing the intermediate
class instance creation?

Thanks,
Anderson.

On Tue, May 10, 2022 at 4:02 PM Stuart Marks <stuart.marks at oracle.com>
wrote:

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