JSR-310, Java-8-Highlights und die Wunschliste für Java 9

Das Date/Time-API aus Java 8: Interview mit Stephen Colebourne

Hartmut Schlosser
Stephen Colebourne

Neben den Lambda-Ausdrücken wird als wichtigstes Feature aus Java 8 immer wieder das neue Date/Time API genannt. Maßgeblich beteiligt am API war Stephen Colebourne, der uns im Interview die Hintergründe erläutert. Zur Sprache kommen auch Stephens persönliche Highlights aus Java 8 und seine Wunschliste für das nun anstehende Java 9.

Java 8 ist erschienen – und mit im Paket enthalten ist das neue Datums- und Zeit-API. Welche Probleme gab es mit dem bisherigen API?

Stephen Colebourne: Die meisten Entwickler sind sich einig darüber, dass das bisherige Java Date/Time API unzureichend war. Die Klassen waren mutable, nicht Thread-sicher, nutzten Null-basierte Indices für Monate und deckten nur ein Minimum ab, während etliche Features fehlten. Die meisten Zeit-sensiblen Projekte haben deshalb schon lange die Joda-Time-Library importiert, um ein besseres API zu erhalten.

Die Behebung des Date/Time-Problems war also nicht primär zeitkritisch – es ging nicht darum, es jetzt zu erledigen, sondern es richtig zu erledigen. Denn was einmal im JDK verankert wurde, lässt sich nicht mehr so einfach verändern.

Was bietet nun das neue API?

Stephen Colebourne: Das neue, im JSR-310 implementierte java.time API liefert ein modernes, vollständiges und einfach zu nutzendes Set an Klassen. Zunächst einmal wird Unveränderlichkeit garantiert. Alle Hauptklassen sind immutable value objects, die frei zwischen verschiedenen Threads geteilt werden können. Das ist insbesondere im Zusammenspiel mit den Lambda-Ausdrücken von Nutzen. Diese Thread-Sicherheit wird, anders als bei DateFormat, auch auf das Formatieren und Parsen ausgeweitet.  

Zweitens bietet das API eine Reihe von Datums- und Zeittypen. Es gibt also unterschiedliche Klassen für die Repräsentation:

–       eines Datums ohne Zeit (LocalDate)

–       einer Tageszeit ohne Datum (LocalTime)

–       eines Jahres (Year)

–       eines Monats (Month)

–       eines Wochentages (DayOfWeek)

–       eines Jahres und Monats (YearMonth)

–       eines Monats und Monatstages (MonthDay)

–       eines Datums und einer Zeit ohne Zeitzone (LocalDateTime)

–       eines kompletten Datums und einer Zeit mit Zeitzone (ZonedDateTime)

–       des augenblicklichen Zeitpunkts (Instant)

Entwickler können nun Daten und Zeiten in ihren Anwendungen repräsentieren, indem sie die korrekten Datumstypen verwenden, anstatt auf Hacks um java.util.Calendar zurückzugreifen. Natürlich bedeutet das, dass sich Entwickler ein wenig mehr Gedanken machen müssen, um den korrekten Typ zu wählen.

Zusätzlich zu den Datums- und Zeit-Klassen werden auch Zeiträume unterstützt:

–       ein Datums-basierter Zeitraum (Period)

–       ein Zeit-basierter Zeitraum (Duration)

Drittens gibt es nun die Unterstützung für eine größere Anzahl an Kalender-Systemen im JDK, beispielsweise das japanische, das thai-buddistische, das Minguo- und das Hijrah-System.

Und schließlich ist ein komplettes Formatierungs- und Parsing-API enthalten, das, anders als DateFormat, voll Thread-sicher ist.

Das API basiert ja auf deinem Joda-Time-Projekt. Gibt es Unterschiede?

Stephen Colebourne: Ich würde für die Unterschiede zwischen dem JSR-310 und Joda-Time gerne auf meinen Blog verweisen: http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941.html (Anm. der Redaktion: Zitat an dieser Stelle vom Blog: „[Joda-Time] does the job it was designed for […]. And it is widely used and without too many major issues. However, after a few years, it is now clear where it could be designed better. I took the decision that I didn’t want to add an API to the JDK that had known design flaws. And the changes required weren’t just minor. As a result, JSR-310 started from scratch, but with an API ‚inspired by Joda-Time‘. „).

Was denkst du persönlich über Java 8? Sind Lambdas der große Game Changer, wie von den meisten behauptet – oder lediglich syntaktischer Zucker?

Stephen Colebourne: Version 8 von Java ist ein gutes Release, das viele interessante Dinge enthält. Ich denke, dass die Lambda-Ausdrücke eine breitflächige Nutzung finden werden, obwohl wir uns alle vor einem übertriebenen Einsatz in Acht nehmen sollten. Vorsichtiger würde ich mich zum Streams API ausdrücken, wo ich nicht immer finde, dass die Gewinne durch die Abstraktion die Kosten aufwiegen. Und ich bin auch sicher, dass die Leute Streams für Dinge verwenden werden, für die sie gar nicht gedacht waren.

Lustigerweise denke ich, dass die wichtigste Sprachneuerung nicht die Lambda-Ausdrücke sind, sondern statische und Default-Methoden bei Interfaces. Obwohl diese auf öffentliche Methoden beschränkt sind, hebt die Möglichkeit statischer Methoden bei Interfaces viele der Use Cases für separate Factory-Klassen auf. Und Default-Methoden entkräften darüberhinaus viele der Gründe für die Nutzung abstrakter Klassen. Architekten und Entwickler werden indes eine Weile brauchen, um herauszufinden, wie man diese Features am besten einsetzt, insbesondere da sie die Makro-Struktur von Anwendungen betreffen.

Welche Wirkung wird Java 8 auf andere JVM-Sprachen haben?

Stephen Colebourne: Java 8 wird die Wettbewerbsfähigkeit von Java gegenüber anderen JVM-Sprachen stärken. Dennoch glaube ich nicht, dass sich viel an der generellen Situation ändern wird. Manager und Entwickler bleiben bei Java, da es im Kern der Community steht, wo alle Energie und Ressourcen zusammenfließen.  Andere blicken über den Tellerrand auf alternative JVM-Sprachen und mögen, was sie dort sehen – zumindest anfangs. Viele davon werden allerdings bald merken, dass auch dort nicht alles Gold ist, was glänzt.  

Java 8 ist nun da – die Planung für Java 9 steht an. Welche Features würdest du dort gerne sehen?

Stephen Colebourne: Die Version 9 von Java könnte so viele Neuerungen bringen. Das wichtigste neue Feature, über das gesprochen wird, sind wohl die Value Types. Allerdings gibt es Anzeichen, dass diese womöglich erst in Java 10 ein Thema sein werden. In Java 9 sollen jetzt die Module wieder angegangen werden, wobei mich das persönlich nicht übermäßig begeistert. 

Ich selbst würde gerne wieder einen Ansatz wie in Project Coin (Anm. der Redaktion: Project Coin war Teil von Java 7) verfolgen, mit dem Ziel, sechs bis zehn kleinere bis mittlere Features umzusetzen. Package/private Methoden in Interfaces wäre ein solches Feature, für das ich mich stark machen würde. Außerdem eine Art zu verhindern, dass statische Methoden auf Klassen von Unterklassen vererbt werden. Und eine Zwischennote: Mein Blog erhält mehr Zugriffe auf Themen über das Fehlen von Multi-Line Strings in Java als über fast alles andere, was man als fehlendes Feature in Java betrachten könnte.

Stephen, vielen Dank für dieses Interview!

Stephen Colebourne ist Java Champion und Rock Star Speaker auf internationalen Konferenzen wie JavaOne, Devoxx und JAX. Er beschäftigt sich mit Java seit der Version 1.0 und leitet seit 2000 Open-Source-Projekte. Stephen hat wichtige Beiträge zum Apache-Commons-Projekt geleistet und ist Gründer der Joda-Open-Source-Projekte, darunter Joda-Time. Als Co-Spec Lead des JSR-310 war er maßgeblich am neuen Date/Time API aus Java 8 beteiligt.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Das Date/Time-API aus Java 8: Interview mit Stephen Colebourne"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Joachim Arrasz
Gast

Thanks a lot for this statement:

"Stephen Colebourne: Version 8 von Java ist ein gutes Release, das viele interessante Dinge enthält. Ich denke, dass die Lambda-Ausdrücke eine breitflächige Nutzung finden werden, obwohl wir uns alle vor einem übertriebenen Einsatz in Acht nehmen sollten."