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…

 

API-Größe einer Java-Zeitbibliothek

Eine spannende Diskussion zur aktuellen API-Größe von Threeten/JSR-310 findet sich auf deren Mailing-Liste. Dazu hatte ich selber bereits im Juli eine Anfrage gestartet, weil ich neugierig war, welche Auswirkungen die Verschiebung von Jigsaw (Modularisierung des JDK) zur die JDK-Version 9 auf Threeten haben würde.

Es könnte also passieren, daß Threeten entweder die Nutzer der Java-ME (mobile edition) durch seine Größe ärgert oder daß Threeten dort sang- und klanglos nicht aufgenommen wird.

Generell wirken die Bemühungen von S. Colebourne, das API zu verkleinern, auf mich etwas verzweifelt. Zum Beispiel spart die Entscheidung, den Quartalstyp (QUARTER_OF_YEAR) herauszunehmen, nur wenige Bytes, opfert aber eine in der Finanzbranche verhältnismäßig wichtige Zeiteinheit. Auch wundere ich mich über Colebournes neueste Spekulation auf ein zukünftiges Java-Sprach-Feature namens “class splitting”, das beim Verschlanken des API helfen soll. Ob Jigsaw das aufgreift, steht doch wirklich in den Sternen!?

Aus der Perspektive von Server-Entwicklern, wo das ganze API am ehesten genutzt würde, wirkt die API-Debatte insgesamt beunruhigend, weil sie mit einem Verlust an Features einhergeht. Es geht hier um grundsätzliche Design-Fragen. Man wird sehen, wohin die Reise geht. Es sind nur noch wenige Monate bis zum Feature Freeze des JDK 8 (Februar 2013?), aber noch soviele Baustellen in Threeten vorhanden. Ob dieses Projekt wirklich schon in trockenen Tüchern liegt?

Veröffentlicht unter Java