Interview mit Anatole Tresch zum JSR 354: Money and Currency API

Neuigkeiten von der Insel  –  1 Kommentare

Es gibt viele interessante Menschen in der Java-Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Zum Start habe ich mit Anatole Tresch über den kürzlich veröffentlichten JSR 354 (Money and Currency API) gesprochen.

Anatole, erzähle uns doch ein bisschen über dich. Wie bist du zur Softwareentwicklung gekommen und was machst du heute?

Anatole Tresch, Spec Lead des "Money JSR"

Ich bin nun seit mehr als 20 Jahren in der IT-Branche tätig, also irgendwie so eine Art Fossil. Der erste Rechner war ein HP des Vaters einer meiner Jugendfreunde, gefolgt von technischen Neuerungen wie IBM-PCs, Floppydisks, Commodore C64, Amiga und Harddisks so groß wie Waschmaschinen. Nicht zu vergessen die Goldgräberstimmung beim Erstehen des ersten eigenen x86-PCs.

Softwaretechnisch begann alles, abgesehen von der Assembler-ähnlichen Programmierung der HP-Rechenmaschinen, mit Object Pascal und C/C++. Ich kann mich gut an die Freude erinnern, die wir hatten, nachdem wir es nach stundenlangem Tüfteln geschafft hatten, erfolgreich eine TCP-Verbindung zwischen zwei UNIX-Workstations herzustellen (ist heute ein Einzeiler!), und die Euphorie, mit Java endlich ansprechende und vor allem portable Applikationen bauen zu können, ohne sich tagelang mit Pragma-Anweisungen und "segementation faults" rumschlagen zu müssen.

So habe ich die Entwicklung des Java-Ökosystems von der Pike auf miterleben und in wohl Dutzenden Projekten aller Art mitwirken dürfen. Nach langer Tätigkeit als Managing Partner und Consultant bei einer kleineren Unternehmung bin ich dann zur Credit Suisse gestoßen, wo ich meinen Horizont in Sachen Komplexität erheblich erweitern konnte und es für mich offensichtlich wurde, warum es auch Architektur braucht. Dabei hat es mir das Spannungsdreieck aus technischer Eleganz, wirtschaftlicher Machbarkeit und dem Faktor Mensch angetan. Ich habe sehr großen Spaß daran, andere zu motivieren, sich ihrerseits nicht mit dem Durchschnitt zufrieden zu geben und sich aktiv einzubringen, sei es im Alltag, an Konferenzen, bei JSRs oder was immer jemand erreichen möchte.

Was machst du privat, wenn du nicht gerade in der Java-Welt unterwegs bist?

An erster Stelle kommen da klar meine Frau und meine drei Jungs, die zeitweise recht anspruchsvoll sein können. Ohne die Unterstützung meiner Frau wäre vieles nicht möglich gewesen. Die Zeit mit meiner Frau und die Momente, in denen mir meine Jungs die Welt erklären, sind von unschätzbarem Wert und helfen, die nötige Distanz zum Alltag zu halten. Und dann wären da meine beiden großen Hobbys: Zum einen spiele ich leidenschaftlich gerne Schlagzeug und höre natürlich auch gerne Musik, am liebsten live. Zum anderen bin ich regelmäßiger Besucher des lokalen Gyms, wo ich mich auch physisch richtig fordern kann.

Ihr habt am 13. Mai den JSR 354 veröffentlicht. Erzähle uns doch bitte ein bisschen mehr dazu. Was ist der JSR 354 und welche Vorteile bringt er im Vergleich zu den bereits vorhandenen Java-Features bei der Arbeit mit Geldbeträgen?

Der JSR 354 definiert eine komplette API für Währungen und Geldbeträge und damit zusammenhängender Funktionsbereiche der Algorithmik, Währungskonversion und Formatierung. Der API gelingt dabei der Spagat, gleichzeitig intuitiv, aber dennoch auch sehr mächtig und erweiterbar zu sein. Auch vereinfacht sie durch ihre flexible Architektur die Einbindung in verschiedene Laufzeitumgebungen, zum Beispiel OSGi, Spring und Java EE. Es lassen sich zusätzliche reelle oder virtuelle Währungen mit einem einfachen Service Provider Interface (SPI) leicht ergänzen, ohne dass eine JDK-Extension implementiert und deployt werden muss.

Geldbeträge kombinieren einen Betrag, eine Währung und numerische Aspekte zu einem gemeinsamen Typen. Dabei werden sogar unterschiedliche Implementierungen unterstützt, um widersprüchliche Anforderungen an numerischen Wertebereich und Performanz abbilden zu können. Dies ist ein großer Vorteil im Vergleich zu BigDecimal und Co., bei denen jeder Programmierer die zugehörige Währung zu einem numerischen Wert selbst verwalten muss. Die API definiert einige wenige, aber sehr mächtige Erweiterungspunkte, die auch für die Konversion zwischen Beträgen unterschiedlicher Währung herangezogen werden. Und zu guter Letzt steht eine einfache, aber Thread-sichere Formatierungs-Engine zur Verfügung, die es ebenfalls erlaubt, eigene Formate einfach zu unterstützen.

Wie bist du Spec Lead geworden und was sind deine Aufgaben?

Eigentlich per Zufall. Ursprünglich wurde der JSR von Victor Grazi gestartet. Da Victor nach einem Jahr die Bank verließ, musste dringend Ersatz her. Letztlich hat mich ein Kollege empfohlen, und so kam ich in den Genuss, als Newbie in Sachen JCP einen JSR zu übernehmen, dem es damals drohte, gestoppt zu werden.

Somit war klar, was die Hauptaufgabe war: den internen Diskussionsprozess neu zu starten und aktiv zu steuern, damit die Expertengruppe einen offenen und konstruktiven Dialog führt. Das Ganze natürlich mit dem Ziel, möglichst rasch eine erste Early Draft Review (EDR) zu veröffentlichen, da der JSR damals arg in Verzug war. Den Termin für die EDR konnten wir zwar nicht halten, aber das JCP Exective Committee (EC) hat uns in einem so genannten Renewal Ballot das Vertrauen ausgesprochen, dass der JSR seine Tätigkeit weiterführen soll.

Auch gab es einige handfeste Konflikte zwischen Experten, welche sowohl fachlicher als auch persönlicher Natur waren, die mich als Spec Lead gefordert haben. Und schließlich war die Kommunikation mit einigen EC-Mitgliedern alles andere als einfach, da die involvierten Personen oft keine einheitliche Meinung vertraten. Nicht zu vernachlässigen sind auch die unterschiedlichen Deliverables eines JSRs (API, Spezifikation, Referenzmiplementierung, Technical Compatibility Kit).

Während zu Beginn eines JSR das API-Design noch rege Diskussionen auslöst, ist es bei fortgeschrittenem JSR weitaus schwieriger, interessierte Personen zu involvieren. Glücklicherweise haben verschiedene Kollegen und Organisationen hier außerordentliche Beiträge geleistet, im Speziellen Stephen Colebourne, Werner Keil und Mark Davis, David Beaumont von Google und auch einige Hackergarten-Teilnehmer.

Zusammenfassend habe ich mich wirklich gefreut, dass wir am Ende den JSR erfolgreich über die Ziellinie gebracht haben. Trotzdem ist der JSR noch nicht zu Ende. Die Community ist herzlich eingeladen, in unserem JIRA Verbesserungs- und Erweiterungswünsche zu erfassen und auch die Referenzimplementierung wird laufend verbessert und etwaige Fehler werden korrigiert.

Wird der JSR 354 Teil von Java 9?

So wie es aussieht, wird der JSR 354 nicht als Teil von JDK 9 ausgeliefert werden. Allerdings sehe ich das nicht zwingend als Nachteil. Mit großer Wahrscheinlichkeit wird Jigsaw nebst einem Modulkonzept auch eine Art Repository zur Verfügung stellen, wo die diversen JDK-Module verfügbar gemacht werden. Es spricht für mich eigentlich nichts dagegen, dass der Money JSR nicht ebenfalls in dieses Repository aufgenommen wird, womit er de facto ins JDK integriert ist.

Sind schon weitere Releases geplant und wie soll es weiter gehen?

Ein Maintenance-Release für das API ist aktuell nicht in Planung, jedoch wären wir froh, wenn User ihre Verbesserungsvorschläge und gefundene Fehler in unser JIRA eintragen, damit wir entscheiden können, wann ein Maintenance-Release JSR gestartet werden soll. Auf Seiten der Referenzimplementierung sind bereits einige kleinere Bugfixes gemacht worden, und es ist geplant, in den nächsten Wochen ein erstes Patch-Release zu veröffentlichen.

Wo kann man mehr erfahren?

Am einfachsten geht man auf http://javamoney.org. Diese Seite dient als Einstiegsseite für alle JSR-354-nahen Projekte und Aktivitäten.

Welche weiteren Projekte verfolgst du?

Aktuell steht für mich Apache Tamaya im Vordergrund, wo ich mit einigen anderen Kollegen versuche, eine API und ein Modulsystem zu definieren, das erlaubt, Applikationen, Module, Erweiterungen und Produkte mit einer einheitlichen Zugriffs-API zu konfigurieren, die spezifisch über ein einfaches Konfigurations-Metamodell gesteuert wird.

Wo kann man dich finden?

Elektronisch bin ich am besten über Twitter (@atsticks), Email (atsticks@java.net), LinkedIn, Google+ und Xing zu erreichen. Wer mich persönlich treffen möchte, der kann das entweder im Raum Zürich machen, zum Beispiel an einem der monatlichen Hackergarten, oder an einer der Konferenzen, wo ich sprechen darf. Leider werde ich dieses Jahr nicht die Möglichkeit haben, die JavaOne zu besuchen, hoffe aber, dass es nächstes Jahr wieder klappt.

Vielen Dank für das Interview und weiterhin viel Erfolg mit dem JSR 354 und Apache Tamaya.