@DateTimeFormat Depends on Joda Time

Yesterday’s blog explained the use of the @DateTimeFormat and whilst writing it, I purposely chose to use java.util.Calendar for simplicity as I didn’t want to add an unnecessary dependency into my classpath... and that’s where I came unstuck. I turns out that if you don’t have the following dependency in your POM:

<dependency>
  <groupId>joda-time</groupId>
  <artifactId>joda-time</artifactId>
  <version>1.6.2</version>
  <scope>runtime</scope>
 </dependency>

...you get this exception:

SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: JodaTime library not available - @DateTimeFormat not supported
 at org.springframework.format.support.FormattingConversionServiceFactoryBean$NoJodaDateTimeFormatAnnotationFormatterFactory.getPrinter(FormattingConversionServiceFactoryBean.java:140)
 at org.springframework.format.support.FormattingConversionServiceFactoryBean$NoJodaDateTimeFormatAnnotationFormatterFactory.getPrinter(FormattingConversionServiceFactoryBean.java:1)
 at org.springframework.format.support.FormattingConversionService$1.convert(FormattingConversionService.java:101)
 at...

Is this right? It seems an oblique design decision to rely on Joda time; was it just that Keith Donald left the Joda time dependency in his classpath leading to a touch of dependency creep or a conscious decision to use it because it made his life as a developer easier? I guess that’s the point here, if you’re developing APIs for other people to use, then a little extra care has to be taken when thinking about dependencies as every dependency added to an API usually becomes classpath issue, especially if you're not using a tool like Maven (though why you wouldn't want to use Maven I don't know); hence, the fewer JAR files you have to worry about the better. There is no doubt that Joda time is a very useful library, but there is a viewpoint that says ‘If I’m not using Joda time in my app, why should I’m need it in my classpath?’. Food for thought?