Although Joda is feature rich and more sophisticated than standard Java time, it may not always be the best thing to use. How do I decide if I should use Joda Time or Java Time in any Java code?
Is there some kind of guideline which tells us how to pick the right one depending on our requirements?
Java 8 and Later
Use the Date & Time API included in java.time.*. It's heavily influenced by Joda Time. In fact the main author is Stephen Colebourne, the author of Joda Time.
Prior to Java 8
Joda Time is such an improvement over the Java legacy time library (java.util.Date and java.util.Calendar) that it is almost always the right choice, apart from the following exceptions:
When it is difficult or undesirable to add third party dependencies to your project
When its use in a public interface would cause issues, e.g. getting an ORM to handle both java and Joda time fields
However, in the case of 2) it would still be better to use Joda internally if possible.
Note that on the Joda-Time website it states:
The standard date and time classes prior to Java SE 8 are poor. By tackling this problem head-on, Joda-Time has become the de facto standard date and time library for Java. Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310).
The main contributor to Joda-Time, jodastephen, is also the main contributor for JSR-310, as can be seen on the GitHub repository associated with http://www.threeten.org/. By the way, jodastephen has also a SO handle ...
I think it is safe to state that we can feel comforted and safe with the new Date and Time API as provided in Java 8 onward.
Some additional references:
The Java standard date API is so fundamentally broken that I have often considered simply adding Joda Time to the library extensions of the JVM so that it loaded on the classpath by default with the rest of the Java API.
If you have ever been tasked with retrofitting internationalization and time zones into a legacy Java application and have attempted to use the standard Java API alone, you will understand what I mean. I was able to turn thousands of asinine lines of code into less than a hundred. The productivity boost is inconceivable.
Further the standard Date API is not intuitive, where the fluid Joda API can be picked up in hours not weeks. Your analogy of trying to get to the island that is two miles away, is more akin to the following.
1) A motorboat that will get you to the island in only 6 minutes.
Or...
2) A makeshift bamboo raft tied together with vines during a hurricane steered by a crazy guy whose best friend is a volleyball.
As other answers have stated, the few drawbacks such as the ORM are even becoming non-existent as Hibernate now has plugins that allow for Joda type bean properties to be mapped to database date/time fields. JPA might also have an answer for this as well.
If your desire is for your application to have a minimalist footprint as a desktop application as it pertains to disk space then perhaps Java is not even the right language choice.
One more point:
Java-Time (i.e. Date) is not ThreadSafe but JodaTime is.
So JodaTime is preferred when requirements like
Or else for simple applications Java-Time is okay.
java.time is implemented through immutability. See stackoverflow.com/questions/9303532/…. This works well for both simple and complex applications. Even the api doc states that "All the classes are immutable and thread-safe" (literally quoted from the second paragraph). The old java.util classes on the other hand have several issues. I realize that this answer refers to the latter, but important to make that distinction now.
Update: The old date-time classes shipped with the earliest versions of Java are now legacy, officially supplanted by the java.time classes built into Java 8, Java 9, and later.
Date, Calendar, SimpleDateFormat, and the java.sql.* date-time classes should all be avoided. There is never a need to use these confusing, troublesome, poorly-designed classes. They are entirely replaced by java.time classes. Their only purpose now is for maintaining existing old code. When interfacing with old code, you can convert to/from java.time by calling new methods added to the old classes. For more info on converting, see: Convert java.util.Date to what “java.time” type?.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes. The Joda-Time project inspired the java.time framework. Both are led by the same man, Stephen Colebourne. You can think of java.time as an rewrite/redesign of Joda-Time, all new code but using what had been learned over the years from building the industry’s first comprehensive and sophisticated date-time library.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP (see How to use…).
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
