Fortschritte in Time4J

Eine lange Zeit ist seit meinem letzten Blog-Artikel verstrichen, weil ich all meine freie Zeit in das Time4J-Projekt gesteckt habe. Viele Versionen sind veröffentlicht worden. Heute habe ich die Versionen 3.1 und 4.0 veröffentlicht.

Die Versionslinien 1.x und 2.x sind mittlerweile veraltet und als Experimentierphase zu werten, weil sich das Design der Version 1.0 aus guten Gründen doch inkompatibel ändern musste.

  • Die Versionsline 1.x hatte keine saubere Trennung zwischen lokalen und globalen Typen.
  • Die Versionslinie 2.x war in ihrem Kern für Android einfach zu groß.

Aber die Versionslinien 3.x für Java 6+7 (und in Zukunft Android) sowie die neue Versionsline 4.x für Java 8 sind jetzt ausgereift und stabil. Inkompatible Änderungen habe ich in Zukunft nicht mehr vor. Das ist nun in Stein gemeißelt.

Die neue Version v4.0, so kann man mit gutem Recht feststellen, hat nun endgültig die so vielgerühmte Joda-Time-Bibliothek und auch die in Java-8 eingebaute Zeitbibliothek (JSR-310) überholt, was die Anzahl und Qualität der unterstützten Features angeht. Lediglich einige Kalendersysteme fehlen im Vergleich.

Was fehlt noch? Gibt es ein Problem? Tja, Time4J ist noch so gut wie unbekannt, auch weil ich so gut wie nicht die Werbetrommel gerührt habe, sondern nur auf die Entwicklung fokussiert war. Und ein Marketing-Profi bin ich nicht, muß ich offenherzig bekennen. Trotzdem bekenne ich mich weiterhin zur Pflege und Weiterentwicklung dieser jetzt schon formidablen Bibliothek. Es gibt noch viel zu tun. Die Bibliothek ist bei weitem nicht fertig. Ich habe noch sehr viele Ideen. Allerdings werde ich jetzt die (extreme) Entwicklungsgeschwindigkeit verlangsamen, weil meine Gesundheit und meine Familie nicht weiter vernachlässigt werden dürfen.

 

Unterstützung für Apache Maven in Time4J

Die neue Version v1.1 von Time4J bietet nun direkte Unterstützung für Apache Maven dank der integrierten pom-Dateien, auch ist die neue Version endlich im Maven Central Repository verfügbar. Der Funktionsumfang ist im Vergleich zu v1.0 praktisch gleich geblieben.

Für alle Anwender, die NICHT Maven als build-Tool verwenden, gibt es den folgenden Link zum Download:

https://github.com/MenoData/Time4J/releases/tag/v1.1

Time4J-Kern fertig

Gerade ist die neue Version v1.0 von Time4J in ihrem Kern fertig. Sie ist unter der Lizenz LGPLv2.1 erhältlich (die gleiche Lizenz wie sie Wildfly (früher JBoss) verwendet). Diese Version ist nunmehr produktionsreif erhältlich. Folgender Link kann für den Download verwendet werden:

Release v1.0

Und die nächsten Aufgaben warten schon: Intervalle und Formatierung von Zeitdauern (milestone M3).

Time4J endlich erschienen

Lange angekündigt, ist meine Java-Datums-und Zeitbibliothek Time4J in der Version v0.1-alpha veröffentlicht worden. Wo? Zu finden auf:

http://github.com/MenoData/Time4J

Zweieinhalb Jahre harter Arbeit liegen da hinter mir, und meine Familie hat schon einige Male ganz schön geseufzt. Aber ich denke, das Ergebnis kann sich sehen lassen, auch wenn natürlich dieser Erstversion noch einige Features fehlen. Und nach der Arbeit ist bekanntlich vor der Arbeit. Die Entwicklung bleibt nicht stehen, sondern geht selbstverständlich weiter. Schwerpunkt des nächsten Release v0.2-alpha werden die Umstellung der Dokumentation auf Englisch, extra Tutorials und mehr Zeitzonen-Features sein.

Über die “Java-Zeitskala”

Kurzmitteilung

Wegen der “Java-Zeitskala” habe ich eine Debatte mit den Erfindern dieser Zeitskala losgetreten. Nicht, daß ich den POSIX-Standard gut fände, aber ich befürworte eine gewisse Konsequenz, die meiner Meinung nach im JSR-310 etwas fehlt. Außerdem bin ich der Meinung, daß eine Zeitbibliothek an POSIX nicht vorbeikommt und eine UTC-Unterstützung nur parallel und nicht ersatzweise anbieten sollte.

Die neue Zeitbibliothek von Java8 – Eine Rezension

Am 4. Dezember 2013 geht der sogenannte “Public Review” des JSR 310 zu Ende. Das ist eine gute Gelegenheit für eine umfassende Rezension. Das vorgeschlagene API hat sich endlich auch stabilisiert. Vorher war es so häufig großen Änderungen unterworfen, daß eine frühe Rezension schnell überholt gewesen wäre. Diese Rezension überläßt Code-Beispiele gerne dem Oracle-Tutorial und fokussiert sich mehr auf das allgemeine Design und die Benutzbarkeit des APIs. Detaillierte Code-Vergleiche und Code-Inspektionen hätten auch den Rahmen dieser Rezension gesprengt. Kalendarisches Spezialwissen ist neben guten Kenntnissen des JSR-310 sicherlich auch nötig, um die Tiefen dieser Rezension zu erfassen. Also eher eine Rezension für anspruchsvolle Entwickler.

Die großen Vorteile auf einen Blick

  • Immutable und thread-safe (unveränderlich – sicher in der Parallelverarbeitung)
  • Fluent Style (flüssiger Programmierstil)
  • Einführung neuer elementarer Datentypen wie: Reines Datum (LocalDate) oder reine Uhrzeit (LocalTime), das ist ein Riesengewinn im Vergleich zum alten JDK
  • Extra Formatfabrik zur programmatischen Erstellung individueller Zeitformate
  • Nano-Präzision zur Abbildung einiger Datenbankzeitstempel
  • Differenzberechnungen (mit Hilfe von java.time.Period und java.time.Duration)
  • API für julianische Tage (siehe Klasse java.time.temporal.JulianFields)
  • API für zeitzonenrelevante Abfragen (z.B. ZoneOffsetTransition#isGap())
  • Umalqra-Kalender für Saudi-Arabien (ein Verdienst von Oracle und Roger Riggs)
  • Allgemeiner Mechanismus für benutzerdefinierte Abfragen und Manipulationen via TemporalQuery und TemporalAdjuster

Können wir uns jetzt alle zufrieden zurücklehnen und sagen: Ende gut, alles gut? Für die meisten Business-Entwickler mit eher geringen Ansprüchen und Erwartungen mit Abstrichen ja, für anspruchsvolle Entwickler leider nicht. Ich kann eine noch längere Liste von Nachteilen präsentieren. Schauen wir uns alles noch einmal im Detail an. Weiterlesen

Kleine Verzögerung

Status

Seit einiger Zeit nichts mehr geschrieben, die Sommerpause war lang. Das heißt aber nicht, daß ich untätig war. Einige extreme private Umstände in meinem Umfeld (neues Baby, Krankenhausaufenthalte etc.) haben dazu geführt, daß ein Ein-Mann-Projekt wie Time4J nicht mit den gleichen hohen Anstrengungen wie vorher weitergeführt werden konnte. Konkret bedeutet das erst mal nur, daß das erste Release nicht wie angekündigt im Spätsommer/Herbst erscheinen kann. Ich hoffe aber immer noch, daß es spätestens im Dezember klappt, wenn auch nur mit einem an Features reduzierten Release.

An der Tatsache, daß ich leider nur relativ wenig Zeit in das Projekt investieren kann, wird sich wegen meiner privaten Situation so schnell nichts ändern. Darum werde ich auch demnächst wenig bis gar nichts bloggen, sondern lieber meine wenige vorhandene Zeit in Time4J stecken so gut es geht. Eine Ausnahme werde ich aber machen, wenn der “Public Draft Review” (PDR) des JSR 310 erscheint. Die neue Zeitbibliothek des JDK von Oracle und Stephen Colebourne steht kurz vor dem Abschluß. Dazu werde ich eine ausführliche Stellungnahme im Blog abgeben, fest versprochen.

Die Mühsal mit java.util.Date & Co

Eine Weile  her hatte ich mich im deutschen Java-Forum für Anfänger in eine Debatte über die Altersberechnung eingeschaltet.

Die Frage zielte darauf ab, wie ausgehend vom Geburtsdatum (gegeben durch Jahr, Monat und Tag als Strings) das Alter einer Person berechnet werden kann. Es klingt einfach, wenn die richtigen Bibliotheken verwendet werden. Alle folgenden Code-Listings entsprechen nicht exakt dem Debattenstand, verfälschen aber nicht die algorithmischen Grundideen. Weiterlesen

UI-Control für Datumseingaben

Die Swing-Technologie für Java, um Desktop-Anwendungen mit einer anspruchsvollen Oberfläche zu erzeugen, ist inzwischen von Oracle mittelfristig abgekündigt. JavaFX gilt jetzt als der Nachfolger (und ich habe gehört, ca. 100 Entwickler lässt Oracle daran arbeiten!). Lohnt es sich noch, sich mit Swing zu beschäftigen? Tatsächlich gibt es trotz bemerkenswerter Features in JavaFX noch mindestens eine UI-Komponente in Swing, die es bis jetzt leider nicht nach JavaFX hinein geschafft hat, nämlich die Klasse javax.swing.JFormattedTextField. Das ist sehr schade, handelt es sich doch um eine sehr mächtige Texteingabekomponente mit anspruchsvoller Anzeige- und Eingabe-Formatunterstützung. Ich konzentriere mich hier vor allem auf die Datumsformatunterstützung. Weiterlesen

Veröffentlicht unter Java

Threeten/JSR 310 im compact-1-Profil des JDK 8

Ich hatte früher noch geschrieben, daß keineswegs sicher ist, ob das Threeten-Projekt wirklich schon in trockenen Tüchern liegt. Auch dessen Projektleiter Stephen Colebourne hatte mal leichte Zweifel angemeldet. Zuletzt hat sogar ein Mitglied des Exekutivkomitees im JCP (Java Community Process) Zweifel gehabt (Werner Keil), siehe auch seine Kommentare auf java-forum.org Begründet hat er das mit der Größe von Threeten, aber auch mit der seiner Meinung nach nicht so gelungenen Interoperabilität mit dem Rest des JDK.

Aber nun verdichten sich doch stark die Anzeichen, daß der JSR 310 nicht nur irgendwie ins JDK rutschen wird. Er ist jetzt entsprechend den Mailing-Listen des OpenJDK-Projekts ausdrücklich für die Basisversion des JDK vorgesehen, tatsächlich für das sogenannte compact profile No. 1, das auch andere Basispakete wie java.lang/java.io/java.util etc. enthält. Außerdem hat der JSR 310 mittlerweile ein relativ starkes Argument gegenüber Bedenken, die auf die Größe des Projekts hinweisen – im Hinblick auf die Eignung für kleine Mobilgeräte wie smart phones. Es ist mittlerweile beschlossene Sache, daß die alte Zeitzonendatenbank im Ordner lib/zi mit ihren vielen binär kodierten Zeitzonendateien durch eine viel schlankere tz-Datenbank als (komprimiertes) jar-Archiv ersetzt werden wird. Allein das spart so viel, daß die Größe des JSR 310 damit wohl genügend kompensiert wird.

Wir werden also in Zukunft eine im Vergleich zu den alten Datums- und Kalenderklassen stark verbesserte Zeitbibliothek sehen. Und wenn dann noch meine externe Time4J-Bibliothek für High-End-Ansprüche im Spätsommer dazukommt, wird Java in Sachen Datum und Zeit richtig gut im Vergleich zu seinen Mitbewerbern à la .NET, PHP, Perl etc. Freuen wir uns. Java auf der Überholspur.

Veröffentlicht unter Java