Wann wenn nicht jetzt?

Beim Stöbern in Quellcode bin ich letztens wiedermal über eine lustige Zeile gestoßen:

...
System.currentTimeInMillis() //we can get the time in milliseconds after 1 Jan 1970 at 0:00:00am GMT
...

Auf den ersten Blick harmlos. Was soll da schon passieren? Ich will die Frage umformulieren: Was passiert danach? Mit dem Wert wird in der Regel angefangen zu arbeiten. D.h. Tage werden hinzugefügt, abgezogen um z.B. Startzeitpunkte zu ermitteln. Dabei wurde in dem Code, den ich gesehen habe in etwa folgendes gemacht:

final long now = System.currentTimeInMillis();
final long oneDay = 1000 * 60 * 60 * 24;
final long tomorrow = now + oneDay;
...

Sieht immer noch alles harmlos aus? Dann weiter …

Ein Tag hat 24 Stunden

An einer anderen Stelle wurde ein Vergleich zweier Daten durchgeführt. Hier die anonymisierte Fassung:

final long oneDay = 1000 * 60 * 60 * 24;

final Calendar calendar = Calendar.getInstance();
calendar.set(2009, 9, 24, 10, 0);
final long summerTime = calendar.getTimeInMillis();

final Calendar comparisonCalendar = Calendar.getInstance();
comparisonCalendar.set(2009, 9, 26, 10, 0);
final long winterTime = comparisonCalendar.getTimeInMillis();

final long difference = winterTime - summerTime;

if (difference == 2 * oneDay) {
    ...
}

Immer noch harmlos? Der ein oder andere wird jetzt sagen: klar. Leider steckt der Teufel im Detail. Was meistens vernachlässigt wird ist die europäische (Un)Sitte zwischen Sommer- und Winterzeit zu wechseln oder auch ganz allgemein alle 4 Jahre mal einen Tag im Februar mehr einzuplanen. Hier muss sich dieser Ansatz leider geschlagen geben.

Ich muss mich an dieser Stelle entschuldigen, denn ich habe den Code bereits so abgeändert, dass das Problem der Sommer- und Winterzeit offensichtlich wird. Der Originalcode sieht natürlich etwas anders aus. Aber nun sollte definitiv ersichtlich werden, warum das nicht funktionieren kann. Hier wird mit festen Zeitintervallen (oneDay) gearbeitet. Leider hat der Tag zum Zeitwechsel nicht 24, sondern entweder 23 oder 25 Stunden.

Geht man mit Java-Hausmitteln an dieses Problem landet man dann aber auch schnell in Code-Schnippseln wie dem Folgenden:

...
Calendar calendar = Calendar.getInstance();
Date now = calendar.getTime();
calendar.add(Calendar.HOUR_OF_DAY, 1);

...

oder die Alternative für den Vergleichscode:

...
Calendar calendar = Calendar.getInstance();
calendar.setTime(2009, 9, 24, 10, 0);
calendar.add(Calendar.HOUR_OF_DAY, 2);

Calendar comparisonCalendar = Calendar.getInstance();
comparisonCalendar.setTime(2009, 9, 26, 10, 0);
if (calendar.getTimeInMillis() == comparisonCalendar.getTimeInMillis()) {
...

Damit löst man zwar das Problem mit der Zeitumstellung, aber auf Dauer ist schön was anderes, denn ein weiterer Schwachpunkt der API, aus meiner Sicht, ist die schlechte Lesbarkeit. Denn wer sieht schon auf den ersten Blick, dass hier nicht der September, sondern der Oktober gemeint ist. Ja, man kann auch mit den Calendar-Konstanten arbeiten, aber auch das führt eher zu unnötig langen Codezeilen.

… einer, der der Macht das Gleichgewicht bringen wird …

Eine elegante Lösung hierfür bietet – nein nicht Skywalker, sondern – die Joda-Bibliothek. Diese erlaubt es das Millisecond-Massaker zu umgehen und die Schwächen der Standard-API zu minimieren. So sieht der Code von oben mit Joda etwa so aus:

...
DateTime dt = new DateTime();
DateTime oneDayLater = dt.plusDays(1);
DateTime oneDayEarlier = dt.minusDays(1);
...

Auch Vergleiche wirken wesentlich angenehmer:

final DateTime now = new DateTime();
final DateTime before = now.minusDays(100);
final Days days = Days.daysBetween(before, now);
if (days.getDays() == 2) {
...

“Schneller, leichter, verführerischer”

Auch wenn das nur ein erster Blick auf Joda war, zeigt sich hier schon die Eleganz und Mächtigkeit dieser Bibliothek. Wer sich nicht scheut ein wenig englisch zu lesen, sei für weitere Informationen auf das IBM-Tutorial Joda-Time und die Website http://joda-time.sourceforge.net selbst verwiesen.

Ansonsten, sehen wir uns in 900 Jahren um Mitternacht

final LocalDate localDate = new LocalDate();
final DateTime then = localDate.toDateMidnight().toDateTime().plusYears(900);

Einen etwas anderen Ansatz verfolgt an dieser Stelle das Framework Wicket. Hier wird bewusst auf eine explizite Expression Language verzichtet – soweit ich sehen kann. Alle Referenzen zwischen Controller und View werden über eine Wicket-Id-Tag (<span wicket:id="myMessage"></span>) aufgelöst. Damit steht zwar der Controller in der Pflicht alle Inhalte entsprechend umfangreicher aufzubereiten (z.B. explizite Änderungs-Propagierung), aber diese Vorgehensweise hat den elementaren Vorteil, dass Seiten wesentlich einfacher auch mit z.B. Junit-Tests geprüft werden können.

Es wäre alles zu schön um wahr zu sein, wenn es nicht schon auf den/meinen ersten Blick ein kleines Problem gäbe. Natürlich geht Wicket von einem MVC-Ansatz aus und benötigt damit HTML-Dateien zum Rendern. Leider wird standardmäßig davon ausgegangen, dass die HTML-Dateien im gleichen Verzeichnis liegen wie die entsprechende Klasse.

“First we need to create a web page. Wicket has a WebPage class suited for this task. All webpages need to be subclasses of WebPage. Another requirement is that the actual HTML file and the class name are equal: Index.html and Index, IndexPage.html and IndexPage or HelloWorld.html and HelloWorld. They also need to be in the same place on the classpath. The best way to develop is to put them in the same directory. This might seem strange in the beginning, especially when you are accustomed to separate html files and java files. However, since all pages are actually just components, it makes perfect sense in terms of reusability.”

(siehe hierzu http://cwiki.apache.org/WICKET/newuserguide.html#Newuserguide-TheHTML)

Für jeden Webentwickler, der es gewohnt ist, dass HTML- respektive JSP(X)-Dateien gefälligst weit weg von den Klassen zu liegen haben, eine Umstellung die nur leidlich zu ertragen ist.
Zum Glück haben die Wicket-Entwickler hier aber ein Einsehen und bieten in der Referenz-Dokumentation auch gleich mehrere Lösungen an, wobei aus meiner Sicht, die Maven-Lösung zu empfehlen ist, da sie versionsunabhängig ist.