Chronology crunchin’

The new Java 8 Date and Time API: An interview with Stephen Colebourne

Hartmut Schlosser

Why was this new feature so critical, and could static and default methods on interfaces be more important than the all-singing, all-dancing lambdas?


Lambda expressions have been getting a lot of lip service over the past week – closely followed by Java 8’s new Date and Time API. In this interview, we talk to Stephen Colebourne, who was instrumental in bringing the latter feature to life. He also explains why it was so important to revise the existing Java API, and what his other highlights are in Oracle’s latest release.

JAX: Java 8 finally has a new Date and Time API. Why was this so urgently needed? What big problems does it fix?

Colebourne: Most developers recognise that the existing Java date/time API is poor. The classes are mutable, not thread-safe, use zero-based indexes for months and are minimal, lacking many features. Most sensible projects have long since imported Joda-Time to get a better API.

Fixing this was primarily a matter of getting it “right”, not fixing it “now”. After all, once something is in the JDK it cannot be easily changed.

What does the new API offer?

The new JSR-310 java.time API provides a modern, comprehensive and easy to use set of classes.

Firstly it provides immutability. All the main classes are immutable value objects that can be freely shared between multiple threads. This is particularly useful in relation to lambdas. This thread safety extends to formatting and parsing unlike DateFormat.

Secondly, it provides a range of date/time types. Thus, there are separate classes to represent:

– a date without time (LocalDate)

– a time-of-day without date (LocalTime)

– a year (Year)

– a month (Month)

– a day-of-week (DayOfWeek)

– a year and month (YearMonth)

– a month and day-of-month (MonthDay)

– a date and time without time-zone (LocalDateTime)

– a full date and time complete with time-zone (ZonedDateTime)

– an instantaneous point in time (Instant)

Developers can now represent date/time in their applications using the correct data type rather than resorting to hacks around java.util.Calendar. Of course this does mean that developers have to *think* a little bit more in order to choose the correct type.

In addition to date/time classes, there are /amounts/ of time.

– a date-based amount (Period)

– a time-based amount (Duration)

Thirdly, there is full support for a wider array of calendar systems in the JDK. This includes Japanese, Thai Buddhist, Minguo and Hijrah calendars.

Finally, there is a full formatting and parsing API. And that API is fully thread-safe, unlike DateFormat.

The API is based on your Joda-Time project. Are there differences between the implemented Java 8 Date & Time API and jodatime?

The differences between JSR-310 and Joda-Time are covered here.

What do you personally think about Java 8? Are lambdas the big game changer everybody is talking about, or just ‘syntax sugar’?

Version 8 of Java is a good release with lots of interesting things. I think lambdas will be well used although we should all be on the lookout for overuse. I am more cautious about the streams API, where I do not always find the abstraction is worth the cost. I’m also certain that streams will be used for things that they weren’t designed for.

Funnily enough, I think the most important language change isn’t lambdas, but static and default methods on interfaces. Although they are limited to public methods, the ability to have static methods on interfaces removes many of the use cases for separate factory classes, and the addition of default methods removes many of the reasons to use abstract classes. It is going to take architects and developers a while to figure out how best to use this, particularly as it affects the macrostructure of applications.

What impact do you think Java 8 will have on other JVM languages, if any?

Version 8 of Java will help Java compete with other JVM languages. However, I don’t think it greatly changes the arguments. Managers and developers stay with Java because it is the core and centre of the community, where all the energy and resources live. While some people look over the wall at other JVM languages and like what they see initially, a good proportion eventually figure out that life isn’t a bed of roses on the other side.

Now Java 8 is here, Java 9 needs to be planned. What would you like to see implemented in Java 9?

Version 9 of Java could contain so many things. The main one being talked about is value types, however are indications that is more likely to be in v10. Modules are supposed to be in 9 now, but do not overly excite me.

Personally, I’d like to see a second Project Coin type approach, providing 6 to 10 smaller/medium features. Providing package/private methods in interfaces would be one I’d argue for, as would be a way to prevent static methods on classes from being “inherited” by subclasses. As a side note, my blog receives more hits about the absence of multi-line strings in Java than almost anything else which might be a clue to a missing feature.

Hartmut Schlosser
Content strategist, editor, storyteller - as online team lead at S&S Media, Hartmut is always on the lookout for the story behind the news. #java #eclipse #devops #machinelearning #seo Creative content campaigns that touch the reader make him smile. @hschlosser

Inline Feedbacks
View all comments