Es gibt aber auch Dinge in Java oder der API, die haben mich in den letzten acht Jahren immer wieder wahnsinnig werden lassen. Beispielsweise der Umgang mit Zeitangaben. Allein, daß sich Calendar im Package java.util befindet, drückt doch schon eine gewisse Geringschätzung aus...

Wer Businessanwendungen schreibt hat es täglich mit Zeitangaben in seinen Anwendungen zu tun wie: jeden Tag um acht Uhr, sieben Stunden lang oder vom ersten bis zum zehnten jeden Monats. Für all das bietet das JDK nur Date und Calendar als Ausdrucksmittel. Beide Klassen beziehen sich vereinfacht gesagt immer auf einen konkreten Zeitpunkt unter Angabe von Tag und Uhrzeit. Beides stellt also einen festen Punkt auf einer Zeitachse dar.

Damit lassen sich aber die oben genannten Beispiele nicht ausdrücken. "Vom ersten bis zum zehnten" bezieht sich auf zwei Punkte auf der Zeitachse. Sollen Fragen wie "Liegt folgendes Datum im Zeitraum oder davor oder sogar danach?" zwingt uns die API immer mit zwei Datumsangaben zu hantieren. Sollen zwei Datumsangaben mit Calendar noch schnell mit Tages oder Monatsgenauigkeit überprüft werden, läßt sich das auch nicht in einer Zeile bewerkstelligen, da Calendar-Instanzen immer auch Zeitangaben enthalten.

Eine neue API für den Umgang mit Zeit ist also mehr als überfällig und Rettung naht auch schon in Form des JSR 310 Date and Time API der unter der Leitung von Stephen Colebourne und Michael Santos entwickelt wird.

Colebourne ist übrigens auch verantwortlich für das JodaTima-Projekt, welches heute schon eine alternative API für Zeitberechungen bereitstellt und von http://joda-time.sourceforge.net/ heruntergeladen werden kann.

Die Grundkonzepte von JodeTime sind die folgenden Datentypen:

• Instant für einen Punkt auf der Zeitachse mit Nanosekundenauflösung
• Interval für einen Zeitraum zwischen zwei Punkten auf der Zeitachse
• Duration für eine Zeitdauer in Milisekunden wie zum Beispiel 3 Tage
• Period für Zeitdauerangaben unter der Verwendung von Jahren, Monaten etc. vergleichbar mit xs:duration

Um diese Datentypen bauen Colebourne und Santos nun auch die API für den JSR 310 auf die eventuell schon in der 7er Version von Java unter javax.time enthalten sein wird. Dazu kommen die notwendigen Klassen zur Verarbeitung von Datumsangaben. Insgesamt hinterläßt die API einen sehr mächtigen Eindruck. Zur Zeit ist sie leider noch sehr instabil, wer aber die Mailingliste zum JSR 310 verfolgt, merkt das aktiv an der Spezifikation und Implementierung gearbeitet wird. Einen guten Überblick über die verfolgten Ziele liefert auch die Präsentation von Colebourne auf der 2008er JavaOne.

Wer bis zu Version 7 nicht warten will, kann jetzt schon bei JodaTime Hilfe finden.

• wechseln in das Portsverzeichnis <PORTSDIR>java/jdk15/
• übersetzen und installieren mit make install clean

Fertig. Sicherheitshalber erzeugt man sich ein Package mit make package. Blieben nur zwei kleine Probleme. Zum einen werden 2,5 GB freier Speicherplatz benötigt und in Abhängigkeit von der Rechnerausstattung konnte der Build mehr als einen Tag einnehmen.

Endlich ist damit Schluß! Seit letzter Woche stellt die FreeBSD-Stiftung fertige Packages des 1.6er JDK auf seiner Webseite zum Download bereit.

Vielen Dank!

P.S.: Wer FreeBSD als offizielle Java-Plattform unterstützen will, kann hier an die FreeBSD-Stiftung spenden.

Beim Vergleich mit offiziellen Zertifizierungen fällt aber immer auch auf, daß die Randbedingungen dort strenger sind. So werden beispielsweise die Prüfungen für eine offizielle Sun-Zertifizierung als Sun Certified Java Programmer bei Partnern von Sun vor Ort abgelegt, ohne das Hilfmittel wie Web-Zugriff und ähnliches erlaubt sind. Dies sollte bei Vergleichen immer bedacht werden.

Doch ein Kritikpunkt bleibt: wie bei so vielen Tests handelt es sich nur um Multiple-Choice-Aufgaben die Faktenwissen prüfen, aber keine Lösungskompetenz. Zwar gilt das auch für die meisten Zertifizierungen, doch nur auf den unteren Stufen. Für höhere Zertifizierungsstufen erfordern fortgeschrittenere Tests auch die Bearbeitung von Fallballspielen.

Auf jeden Fall ist es positiv, wenn die Teilnahme bei JavaBlackBelt jetzt einfacher ist, ohne daß man zwingend eigene Fragen entwickeln muß, um genügend Community-Punkte für den nächsten Gürtel zu aufzubauen. Denn je größer die bestehende Fragensammlung ist, derzeit soll sie bei 31.210 Fragen liegen, desto schwieriger ist es, wirklich gute Fragen beizusteuern, die einen Mehrwert habe und nicht nur um der Punkte willen entwickelt wurden.