Software Engineering Blog

Seit Oracle Sun gekauft hat, steht oft die Frage im Raum, welche Sun-Produkte und -Geschäftsfelder Oracle fortsetzen will. Oracles offzielle Stellungnahme kann hierzu unter der URL http://www.oracle.com/ocom/groups/public/documents/webcontent/038563.pdf gefunden werden.

Liebe ich Java? Ja, das tue ich. Sicher, Java muß aufpassen nicht den Anschluß an die Entwicklung "moderner" Sprachkonzepte zu verpassen, aber etwas moderater Konservatismus kann nicht schaden. An vorderster Front zu stehen kann auch gefährlich sein und tödlich. Außerdem geziemt es sich nicht für eine "Business-Language" sich in jedes Getümmel zu stürzen.

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.

Die Java-Entwicklung unter FreeBSD hatte bis jetzt immer einen entscheidenen Nachteil: das JDK mußte man sich selber übersetzen.
(weiterlesen...)

Bei der Durchsicht meiner Mails bin ich auf den letzten JavaBlackBelt-Newsletter gestoßen. War bisher nur der Gelbe Gürtel ohne eigenen Beitrag zur Sammlung von Prüfungsfragen zu erreichen, kann jetzt der Grüne Gürtel erreicht werden. Für die nächst höheren Gürtel müssen Mitglieder aber weiterhin neue Beiträge zur Fragensammlung leisten.
(weiterlesen...)