Eine recht interessante Kurz-Debatte zur Anwendung von Java-Generics findet sich im Issue-Tracker des JSR-310-Projekts. Folgende generische Methodendefinition liefert leider keine Compile-Time-Type-Safety, wie Stephen Colebourne richtig festgestellt hat:
<R extends Temporal> long between(R dateTime1, R dateTime2);
Ein erstes Java-Projekt als Miniatur-Variante des noch kommenden Time4J-APIs ist ab sofort öffentlich und als Open Source unter der GPL-v3-Lizenz nutzbar. Weitere Einzelheiten und Links zum Herunterladen siehe den obigen Projektreiter.
Pünktlich zum von Esoterikern postulierten Weltuntergangstag am 21. Dezember 2012 endet die von den meisten Wissenschaftlern und Archäologen angewandte sogenannte Lange Zählung des Maya-Kalenders (englisch: long count). Ja, eventuell sehen das manche Esoteriker das sogar als “Beweis” für ihre Weltuntergangsphantasie an. Wie auch immer, die Maya haben nach neueren archäologischen Funden wohl schon darüber hinausgezählt. Interessant hierzu auch das Interview mit dem deutschen Archäologen und Maya-Forscher Nikolai Grube. Also keine Angst vor dem Weltuntergang.
Ist damit der alte Maya-Kalender beendet? Im historischen Sinne nach dem Kriterium des alltäglichen Gebrauchs ist er es schon längst. Aber ich habe beschlossen, ihn ein winziges Stück weit für historisch Interessierte weiterleben zu lassen. In meinem Projekt Time4J – eine neue Datums- und Zeitbibliothek geschrieben in der Programmiersprache Java – wird es auch eine MayanDate-Klasse geben. Kalendarische Grundlage wird der englischsprachige Eintrag zum Maya-Kalender in Wikipedia sein. Wie dort schön zu sehen ist, sind die kalendarischen Algorithmen des Kalenders erstaunlich einfach, deutlich einfacher jedenfalls als im modernen ISO-8601-Kalender. Um so mehr erstaunt es, daß z.B. eine so renommierte Bibliothek wie Joda Time so eine Komponente nicht hat. Nicht einmal eine externe Bibliothek mit dem Maya-Kalender basierend auf Joda Time scheint es da zu geben. Das einzige, was ich im Internet gefunden habe, ist ein kleines Applet zum Thema. Da bietet Perl mehr! Höchste Zeit, diesem Mangel von Java abzuhelfen.
Wann ist damit real zu rechnen? Insgeheim hatte ich gehofft, daß Time4J pünktlich zum Weltuntergangstag seine Geburt erleben sollte. Aber manchmal dauern Wunder ein wenig länger, gerade bei der Komplexität der anderen weit wichtigeren Kalendersysteme, die auch zu implementieren sind. Ich glaube eher an Spätsommer 2013. Also noch ein wenig Geduld bitte, verehrte Leser.
Der am natürlichsten wirkende Name “Date” ist bereits seit Java 1.0 durch die Klasse java.util.Date besetzt. Damit in Java-Programmen keine Namenskonflikte entstehen, die nur durch umständliche Zusatzangaben von Paket-Qualifizierern aufgelöst werden können, besteht die Notwendigkeit, wenigstens für die elementarsten und häufig verwendeten Klassen einer JDK-Erweiterung oder externen Bibliothek Namen zu wählen, die noch nicht vergeben sind. Weiterlesen
Streng genommen lautet die Antwort kurz und bündig: NEIN!
Der christliche gregorianische Kalender und der daraus abgeleitete ISO-Kalender sind im Hinblick auf Äras und Jahreszahlen nicht gleich. Was sind die Folgen für Java-Datumsbibliotheken? Weiterlesen
Hier ein paar interessante Links:
Warum ist die gregorianische Schalttagsregel die beste?
Der zweite interessante Link beleuchtet auch die mathematischen Probleme beim Definieren einer geeigneten Schalttagsregelung sehr gut. Die Regel wird zumindest bis in 3200 Jahren richtig sein. Danach müßte eine neue Regel her, aber das Problem ist jetzt nicht aktuell.
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…
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?
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
Zuletzt aktualisiert am 27.09.2012!
Will ich alle jemals existierenden Ansätze und fertige Bibliotheken auflisten, werde ich sicherlich nicht fertig. Die tatsächliche Anzahl ist auch nicht ermittelbar, weil viele Bibliotheken gar nicht öffentlich verfügbar sind. So gibt es in meiner Firma intern eine eigene Datumsklasse und auch eine eigene Uhrzeitklasse, die jeweils als Zustand Jahr, Monat, Tag und Stunde, Minute, Sekunde in Integer-Variablen halten und die Zeitrechnung an das JDK (java.util.GregorianCalendar) delegieren.
Bibliotheken, die lediglich die JDK-Kalenderklassen ummanteln und so einige unschöne Details verstecken und nach außen verbessern, gibt es in Unmengen. Auf diese Art und Weise kann z.B. die vielfach kritisierte Zählung des JDK von Monaten ab 0 (Januar) statt 1 (in der Umhüllung) leicht geändert werden. Eine unsortierte Mini-Auswahl von Open-Source-Bibliotheken dieses Typs sind zum Beispiel:
Ich möchte daher das Thema etwas anders formulieren: Wieviele eigenständige Bibliotheken gibt es, die alle wesentlichen Aspekte einer Zeitbibliothek selbst behandeln, ohne an das JDK zu delegieren und daher auch stand-alone verwendet werden können? Die folgende Übersicht behandelt genau diese. Es sind überraschend wenige, nämlich (nach meinem Kenntnisstand) nur 6, das JDK eingeschlossen! Wer nach dem Kriterium der Eigenständigkeit noch mehr solche Bibliotheken kennt, möge sie mir gerne mitteilen.