And to repeat some of the mistakes of the past, such as having the classes be mutable, and not separating zoned and unzoned times. It also contains some novel wackiness of its own: new instances of JDateTime take default values for some settings (time zone, whether date arithmetic should be clamped to valid dates, etc) from fields in the class JDateTimeDefault; but these fields are static, not final, and public, so any code in the JVM can change them, thus changing the behaviour of JDateTime objects created by completely unrelated code!
As of Java 8, there is a pretty comprehensive and well-designed date-time package in the JDK:
That package was designed primarily by Stephen Colebourne, who designed Joda Time, and essentially constitutes the Joda Time: The Next Generation. I don't see any reason to use JDateTime over this.
