Monday, 12 March 2012

Java World posted one of those recurring questions... No mention to Joda-Time in the article, as if there were no existing alternative to java.util.Date to manipulate dates in Java.

Who codes only using the core libraries of a language ?

How Badly Do We Want a New Java Date/Time API How badly should you learn to use appropriate third party libraries when needed ?

I did get irritated by the java.util.Date, consequence was the lost of hours of my time (necessary to realise how terrible its design was, unless someone had told me).

But see where it live: util.

I believe the lang package is core, its classes are now the only ones I blindly use. Anything util could arguably not even be part of the standard library.

Maintainability concerns already tell us that java.util.Date will always exist, and will remain there.

I wrote an advanced Java application by only using 5 of the 40+ top level classes living in the the util package. But I would still be writing this app right now if I only allowed myself to use the standard libraries.

No we do not even want some new Java Date/Time API at all. Don't only deprecate most of the Date class though, adds mentions in the class itself warning students that this is a very good example of bad design, it will:

1) Save their time.

2) Allow them to ask their lecturer to justify the fact that they are being forced to manipulate the Date object to complete their coursework.

3) Prevent new projects from picking this stupid Date which is not even a date.

Adding a new Date API (say merging Joda-Time in standard library) would only take you that far, try to implement the UI date picker showing as the picture of this post - without a third party lib - enjoy.