Passing Joda Time objects between the App layers

Question

I'm considering using Joda-Time.
I'm wondering if I should pay attention of what type of object my Interfaces are returning.
Returning Joda-Time objects from my interface signature on the service layer means that every module that use it will have be dependent on Joda-Time instead of the common java.util.Date API.
Are you passing Joda objects around your App modules or do you write wrappers in specific part of your app?

Answer 1

In the beginning, only return the most suitable type (Joda Objects in this case).

If you learn that someone has a problem with that (which probably won't happen too often), either add a converter method to the interface (so you have, say, getTime() and now getJavaTime() or getTimeInMillis()).

Or add a general purpose helper method which takes an Object (you can treat an unknown instance as Object anywhere in the code without having to import the actual Joda classes) and returns a plain Java object (java.util.Date).

Answer 2

What is the alternative ? Transforming jodaTime objects into infamous Calendar/Date objects ?

You chose to get rid of these objects and that's a good decision. Now, if you let other layers use the java date API, they'll go into the kind of bugs and non-sensical behaviours you got rid of by using jodaTime.

I think you should do your users a favor and let them use jodaTime.

Of course it's a design decision that'll add in their code a dependency to jodaTime, but I don't find it questionnable, as you chose jodaTime to write less and better code, and so should they.

Answer 3

Now: Joda-Time

Whenever possible, use Joda-Time. Convert to java.util.Date where required to exchange data with other classes that are not Joda-Time savvy.

To go from java.util.Date to org.joda.time.DateTime, pass the Date to a DateTime constructor:

DateTime myDateTime = new DateTime( myDate );

To go from DateTime to Date, call the toDate method:

Date myDate = myDateTime.toDate();

Future: JSR 310

Java 8 brings the java.time.* classes defined by JSR 310. These classes were inspired by Joda-Time but are entirely re-architected.

If your project is used only in Java 8 or later, use these rather than Joda-Time. Joda-Time is still useful on older versions of Java, and Joda-Time is still maintained. But the java.time.* classes are meant to supplant both Joda-Time and the java.util.Date/Calendar classes.

Your question will eventually become moot as other classes and frameworks are updated to replace their usage of java.util.Date/Calendar with java.time.*.

Answer 4

Depending on what you expect client libraries to do with your api, you may opt to use only millisecond time stamps. All else is representation that may or may not be worth passing around. If your library is all about helping in the representation of date and time in a human radable manner, use Joda and it may just work much the same in Java8. If your library is more into coputation with dates, exchange just time in milliseconds and leave it to the client to use whatever they like.