Was macht Time4J?

Mein Projekt wächst und gedeiht. Tatsächlich habe ich ja bereits im Oktober 2011 mit ersten Studien angefangen, so daß ich nicht bei Null beginnen muß. Aber schwer und zeitraubend ist das Projekt schon. Dennoch: Heute habe ich die abstrakten Grundlagen von Time4J fertiggestellt und sie in einem Paket namens de.menodata.time4j.foundation implementiert (mit 8 Klassen, 13 Interfaces, 2 Enums und 2 Annotations).

Ich habe unter anderem eine abstrakte Oberklasse namens TimePoint, die zwar noch keine konkreten Zeitfelder und Zeiteinheiten kennt (z.B. noch keine Monate kennt), aber die gesamte Zeitarithmetik und die Zeitfeldwertabfragen an mit den Feldern und Einheiten verknüpfte Regeln delegiert. Somit kann ein neues komplexes Kalendersystem relativ leicht realisiert werden, indem die komplexe Kalenderlogik in einzelne überschaubare Regeln zerlegt wird. Die abstrakte Klasse TimePoint fügt dann alle Puzzleteile zusammen und definiert allgemeine Methoden wie {Object value = timePoint.get(ChronoField field)} oder {TimePoint newTimePoint = timePoint.add(long, ChronoUnit)} oder {Duration duration = timePoint.subtract(TimePoint)} usw. Veröffentlichen werde ich das bislang erreichte API zur Unterstützung des Kalenderbaus aber erst im Rahmen eines alpha-Release.

Ebenfalls fertig habe ich das wissenschaftlich interessante Feature der UTC-Schaltsekunden, ein absolutes Novum in der Java-Welt. Nun wäre die Integration dieses Features in konkrete TimePoint-Klassen wie UniversalTime (UTC-Variante eines IsoDateTime mit Zeitzone) recht einfach. Es geht also voran!

Das nächste große Thema wird neben konkreten nutzbaren TimePoint-Implementierungen wie IsoDate und IsoTime eine Format-Subbibliothek sein…

 

Probleme mit Threeten => Time4J

Wie in der zuletzt am 27.9.2012 aktualisierten Übersicht von Datums- und Zeitbibliotheken ersichtlich, ist derzeit die für das JDK 8 vorgesehene Bibliothek Threeten (JSR 310) die am besten zu bewertende. Joda habe ich in jenem Artikel nur deshalb empfohlen, weil sich Threeten noch im alpha-Stadium befindet, also ein (sehr) instabiles API hat.

Um Mißverständnissen bezüglich der weiter unten vorgebrachten Kritiken vorzubeugen, sei eins vorausgeschickt. Zweifelsohne ist Threeten für alle Standardanwendungen in Sachen Zeit meist gut geeignet und in der Mehrzahl der Fälle klar besser als die alten JDK-Klassen, auch besser als Joda. Stephen Colebourne, die treibende Kraft hinter Joda und Threeten, hat über die Jahre wirklich enorme Fleißarbeit verrichtet. Inzwischen gibt es auch einen zweiten Early Draft Review (EDR2) des JSR 310 (Version 0.7). Hier zeigt sich allerdings auch schon die Instabilität des ganzen API, denn wenn man stattdessen direkt in den Quelldateien auf GitHub stöbert, stellt man erhebliche Abweichungen des aktuellen Quellcode-Stands vom EDR2 fest. Es ist also etwas schwierig, alleine auf Basis des EDR2 Bewertungen vorzunehmen. Vieles ist teilweise noch stark im Fluß… Weiterlesen