April April! (Entfernung der Time API ;-)

In Zeiten der „Fake News“ sollte man stets den Wahrheitsgehalt von dem hinterfragen was man liest – insbesondere an einem bestimmten Tag im Jahr, wie gestern einer war. :-)

Der JEP-472 und die Entfernung der neuen Date & Time API aus meinem gestrigen Beitrag waren natürlich frei erfunden. Spätestens beim Anklicken der Quellen-Links wäre dies klar geworden.

Tatsächlich ist die java.time-API ein Beispiel für sehr gutes Code Design. Unter anderem werden die folgenden Prinzipien darin konsequent eingehalten:

• Single Responsibility Principle: Jede Klasse hat genau einen Verantwortungsbereich. So gibt es z.B. dedizierte Klassen, die nur eine Uhrzeit (LocalTime), ein Datum ohne Zeit (LocalDate), sowie Datum mit Zeit (LocalDateTime) repräsentieren – alle ohne Ortsbezug (daher „local“). Darüber hinaus gibt es ZonedDateTime, ein Datum mit Zeit in einer definierten Zeitzone.
  Die Legacy-Klassen Date und Calendar enthalten dagegen beide immer Datum, Uhrzeit und Zeitzone. Das bedeutet, bei Verwendung der alten API muss man sich stets mit der Zeitzone herumschlagen, auch wenn diese im aktuellen Problem gar keine fachliche Relevanz hat.
• Interface Segregation Principle: Kleine Interfaces mit wenigen Methoden, die sich auf eine bestimmte Funktionalität begrenzen. Zum Beispiel TemporalAccessor, das von den oben genannten Klassen implementiert wird und dazu dient, Zeitinformationen wie „day of month“ oder „hour of day“ auszulesen. Durch Verwendung der Interfaces statt konkreter Typen wird eine lose Kopplung erreicht.
• Unveränderlichkeit (Immutability): Die Date- & Time-Klassen sind alle unveränderlich. Funktionen zum Rechnen mit Zeitwerten, wie z.B. myDate.plusDays(5), geben daher immer ein neues Objekt zurück. Nebenläufigkeitsprobleme kann es somit per Design nicht geben – im Gegensatz zum alten java.text.DateFormat, das beim Parsen und Formatieren seinen internen Zustand ändert, weshalb dieselbe Instanz nicht ohne Synchronisation in mehreren parallelen Threads verwendet werden darf.
• Principle of Least Astonishment: Wir sind es gewohnt, beim Zählen von Tagen, Monaten etc. mit der Eins anzufangen. Also sind wir überrascht, wenn die Zählung von Monaten plötzlich von 0 bis 11 reicht, die Tage dagegen wieder mit 1 anfangen. Oder wenn von der Jahreszahl 1900 Jahre abgezogen werden. So war/ist es in der alten Date-Klasse.  Dagegen numeriert die neue API alles gemäß unserer Erwartungen, also z.B. die Monate von 1 bis 12.

Es ist richtig, dass die API aus einer großen Zahl von Klassen und Interfaces besteht, so dass man sich tatsächlich ab und zu fragt, welche Klasse man verwenden soll. Das ist einerseits dem Single Responsibility Principle geschuldet – andererseits auch der Fachlichkeit. Denn das Thema „Zeit“ ist viel komplexer als man zunächst annehmen mag.

Auf jeden Fall ist die API sehr gut dokumentiert, und wer auch mal im JavaDoc nachschaut (anstatt immer nur Code-Schnipsel von StackOverflow kopiert ;-) findet sicherlich auch die Antwort auf seine Frage.