I want to convince the architecture manager to include the Joda-Time jar in our product.
Do you know any disadvantages in using it?
I think Joda-Time needs to be constantly updated because of the files that it includes. And that is a disadvantage. Maybe I am wrong.
Could you provide some clarity on the subject?
I've had almost entirely positive experiences with Joda Time. My one problem was when trying to construct my own time zone (for legitimate reasons, I assure you :) I got some very weird exceptions, and the documentation wasn't very good for that particular use case.
However, for the most part it's been a joy to use - immutability makes code a lot easier to reason about, and thread-safety for formatters is hugely useful.
Yes, there are files to keep up to date - but at least you can keep them up to date. It's not like they contain things which were unnecessary with Java's built-in stuff, it's just that with Java's mechanism you just couldn't keep information like timezones up to date without significant hackery!
Basically, +1 for using Joda Time. The Java date/time API is one of the worst bits of the Java platform, IMO.
The biggest issue that we had when using Joda Time was with integration with Spring and Tapestry, as they both wanted to use the built-in Date and Time. We were constantly writing wrappers in getters/setters for date and time: either we would store it as Joda Time and one set of getters/setters passed it through and the other would convert on the fly, and some classes stored it internally as a Java Date/Time, and the Joda getter/setter had to switch it on the fly.
Basically, it was a headache because the classes are similarly named, and unless you can get your entire architecture (including other libraries you're integrating) to switch to Joda Time, you are going to write more wrapper code than you are likely to save by using the Joda libraries.
Parleys hosts a presentation by Stephen Colebourne about JSR-310, Mr. Colebourne the author of Joda-Time and JSR-310. He starts out by explaining the weaknesses of the standard date/time support in Java and why you'd want to use an alternative. It may be helpful to show this presentation to your architecture manager. I can't seem to deep-link
The reason Joda-Time updates its timezone file fairly often is because timezone data changes all the time, often on short notice (today on slashdot: leap second added on 2008-12-31) and not always scientifically motivated (e.g. I recall some pacific island state changed its time zone to be the first country to enter the year 2000).
In the past, I've encountered companies that didn't want to incorporate third party open source software, or at least required the company lawyer to certify that the license wasn't going to expose them to any sort of liability or have a viral effect on their product.
As with any third party libraries, you should probably put it into source control so you can find the version that you shipped with particular releases of your code in case something goes wrong.
