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 →