Chronology crunchin’

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

Hartmut Schlosser
time-for-change

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.


Author
Hartmut Schlosser

Hartmut Schlosser

All Posts by Hartmut Schlosser

Harmut Schlosser is the editor and online coordinator for Software & Support Media’s portals JAXenter.de, Windows Developer and PHP Magazin. He is a specialist in Java Enterprise-Technologies, Eclipse & ALM, Android and Business Technology. Before working at S&S Media he studied Music, Information Studies and French anthropology.
Comments
comments powered by Disqus