JavaMoney: Einführung in den JSR-354-Standard

Von Anatole Tresch

Im Umgang mit Währungen sind Richtlinien und Standards ein großer Vorteil. Dieser shortcut liefert einen Einstieg in JSR 354 und sein API, das den Umgang mit Geldbeträgen in Java standardisiert. Das von JSR 354 definierte Server Provider Interface (SPI) ist sowohl für einfache Anwendungsfälle wie die Erweiterung von neuen Währungen und Rundungen als auch für komplexere Einsatzszenarien geeignet und flexibel einsetzbar. Der Autor zeigt weiterhin, wie neue Währungskonversionen und Formate definiert werden können. Zudem lernen Sie, den JSR mithilfe des Bootstrap-Mechanismus transparent mit CDI im Java-EE-Umfeld zu integrieren.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 26. Apr. 2016
• ISBN: 9783868025880

Buchvorschau

GmbH

1 Eine Einführung in den JSR-354-Standard

JSR 354 standardisiert den Umgang mit Geldbeträgen in Java und ist seit Mai 2015 final. Der Standard wird in verschiedenen Projekten weltweit eingesetzt und läuft stabil. Also höchste Zeit, diesen JSR mal etwas genauer unter die Lupe zu nehmen.

Starten wir mit der Frage, warum die Funktionalität, die uns die Java-Plattform zur Verfügung stellt, nicht ausreicht. Dabei betrachten wir als Erstes die Klasse java.util.Currency. Diese bildet den ISO-4217-Standard [1] ab, der auch die bekannten Abkürzungen wie CHF und USD definiert. Für viele Anwendungsfälle reicht die gebotene Funktionalität vollauf, trotzdem können viele Anforderungen nicht abgedeckt werden. So enthalten ISO-Codes keine Information über ihre zeitliche und geografische Gültigkeit. Wenn man also Daten über längere Zeiträume speichern will, kann es vorkommen, dass eine gespeicherte Währung nicht mehr klar definiert ist. Als Beispiel stelle man sich griechische Drachmen vor, die bei einem Grexit wieder eingeführt worden wären. Der Währungscode enthält keine Informationen darüber, ob es sich um Drachmen aus der Zeit vor der Einführung des Euro oder nach dem Grexit handelt. Verschlimmert wird dies noch, wenn man bedenkt, dass theoretisch der Standard nach zehn Jahren einen nicht mehr benutzten Währungscode neu vergeben kann. Somit hätten wir die Eindeutigkeit ohne zusätzlichen Kontext vollständig verloren. Doch auch in den Codes selbst lauert Erstaunliches. So gibt es mit dem CFA einen Code, der für zwei Länder mit eigenen Legal Entities identisch ist. Oder umgekehrt sind mit USD, USN und USS gleich drei (!) Codes definiert, die allesamt US-Dollar modellieren. Und wer denkt, die drei Codes für US-Dollar seien eine Ausnahme: weit gefehlt! Auch für Schweizer Franken gibt es CHF, CHE und CHW. Im Gegensatz zu den amerikanischen Codes ist aber standardmäßig nur CHF in der Java-Plattform verfügbar. Die vordefinierten Codes sind in speziellen Dateien in der Java-Laufzeitumgebung untergebracht. Will man nun eigene Codes ergänzen, z. B. BTC für Bitcoins oder virtuelle Währungen, wie Lindon Dollars oder Facebook Coins, so muss man selbst in die JRE eingreifen. Bei Mandantenfähigkeit ist dann aber spätestens Schluss. Es kommt hinzu, dass aufgrund der Einschränkungen des ISO-Standards viele Unternehmen ihre eigenen Schlüsselräume