© Excellent backgrounds/Shutterstock.com
Java Magazin
Eine Einführung in den JSR-354-Standard

JavaMoney, Money, Money

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.

Anatole Tresch


ArtikelserieTeil 1: Grundlagen: API und Usage Teil 2: SPI: Basics, Rundungen und WährungenTeil 3: SPI: Konversion, Formatierung und Java EE

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 definiert haben, um Währungen auch über längere Zeiträume eindeutig identifizieren zu können. Diese Lösungen können aktuell nur mittels externer Logik mit dem Currency-Typen verbunden werden. Schließlich ist auch die Formatierung der Währungen stark mit der Currency-Klasse verwoben, obsc...

Java Magazin
Eine Einführung in den JSR-354-Standard

JavaMoney, Money, Money

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.

Anatole Tresch


ArtikelserieTeil 1: Grundlagen: API und Usage Teil 2: SPI: Basics, Rundungen und WährungenTeil 3: SPI: Konversion, Formatierung und Java EE

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 definiert haben, um Währungen auch über längere Zeiträume eindeutig identifizieren zu können. Diese Lösungen können aktuell nur mittels externer Logik mit dem Currency-Typen verbunden werden. Schließlich ist auch die Formatierung der Währungen stark mit der Currency-Klasse verwoben, obsc...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang