Im folgenden der Java Schnipsel wie man eine statische Liste initialisieren würde:

private static final Set VALID_CODES = new HashSet();
static {
  validCodes.add("XZ13s");
  validCodes.add("AB21/X");
  validCodes.add("YYLEX");
  validCodes.add("AR2D");
}

Mit der “Double Brace Initialization” sieht dieser Schnipsel nun wie eine Expression aus:

private static final Set VALID_CODES = new HashSet() {{
  add("XZ13s");
  add("AB21/X");
  add("YYLEX");
  add("AR2D");
}};

Ein häufiger auftretendes Problem ist aber das Initialisieren einer Liste, Map oder Set wenn diese als Methodenparameter übergeben werden soll. In der Regel sieht das dann in etwas so aus:

Set validCodes = new HashSet();
validCodes.add("XZ13s");
validCodes.add("AB21/X");
validCodes.add("YYLEX");
validCodes.add("AR2D");
removeProductsWithCodeIn(validCodes);

Mit der neuen Schreibweise verkürzt sich dieses Stücken Code auf eine Zeile:

removeProductsWithCodeIn(new HashSet() {{
  add("XZ13s");
  add("AB21/X");
  add("YYLEX");
  add("AR5E");
}});

Letztlich ist diese Art des initialen Befüllens nicht wirklich etwas Besonderes – zumindest aus Java Sicht . Die erste Klammer aus der “double brace initialization” erstellt eine anonyme Klasse und die zweite einen Initialisierungsblock innerhalb der anonymen Klasse. Es wird also ganz normale Java Technik verwendet lediglich die neue Art der Schreibweise ist mal etwas anderes.

Nun noch abschließend die wirklich brauchbare Info, dass man sehr einfach eine Liste mit Arrays.asList() initialisieren kann:

List myList = new ArrayList(Arrays.asList("One", "Two", "Three"));

Diese Hilfsmethode Arrays.asList() sollte man sich also merken.

Wie auch immer man eine Liste initialisiert – die “Double Brace Initiliazation” ist mal eine andere Art =)

(Alle Beispiele wurden eins zu eins aus dem entsprechenden Artikel auf 2c.com übernommen)

Integer i1 = new Integer(2);
Integer i2 = new Integer(2);

System.out.println(i1 == i2);      // Ausgabe: false
System.out.println(i1.equals(i2)); // Ausgabe: true

Nun aber die Frage nach dem Überprüfen eines enums. Hat man z.B. folgendes Java enum:

public enum EnumEqualTest {
  EINS, ZWEI, DREI;
}

Und anschließend wieder die folgende Gleichheitsabfrage mit dem System.out:

EnumEqualTest e1 = EnumEqualTest.ZWEI;
EnumEqualTest e2 = EnumEqualTest.ZWEI;

System.out.println(e1 == e2);      // Ausgabe: true
System.out.println(e1.equals(e2)); // Ausgabe: true

Beide System.out’s geben true aus. Der Test zeigt also, dass die Überprüfung mit == für enum Typen funktioniert. Jetzt stellt sich nur noch die Frage ob das auch empfohlen ist. Ähnlich wie bei Strings könnte es ja durch die besondere Behandlung des enum Typs “zufällig” funktionieren.

Um das ganze kurz zu machen: Enum Konstanten sind implizit public static final und somit statische Variablen. Statische Variablen gehören zur Klasse, werden daher mit der Klasse selbst im Heap abgelegt und haben immer die gleiche Referenz. Aus diesem Grund kann man auf die statischen Variablen auch immer nur über die Klasse gelangen wie z.B. EnumEqualTest.ZWEI. Das ist auch der Grund warum man auch mit dem == Operator die Gleichheit überprüfen kann.

Schaut man sich im Quellcode des enum Typs die methode equals() mal genauer an sieht man neben der final Deklaration auch, dass equals() selbst mit dem == Operator die Gleichheit prüft:

Somit ist es eigentlich total egal für welche Variante man sich entscheidet den beide münden im == Operator Ausdruck.
Einen nennenswerten großen Vorteil hat allerdings die Variante direkt mit dem == Operator zu arbeiten: Der Compiler erkennt wenn die Typen nicht zueinander passen:

Es erscheint der Compiler Fehler “Incompatible operand types ... and ...“. Somit erspart man sich lästige Fehler die später gesucht werden müssen.

Nun ist die Erläuterung auf die Frage nach der besseren Variante der Gleichheitüberprüfung von enum Typen doch etwas länger ausgefallen =).

Auf der Rechnung ist schön zu erkennen, dass 38,29 EUR – 38,29 EUR nicht immer 0 ergeben. Jedenfalls dann nicht, wenn man mit Fließkommazahlen rechnet. Und da der ausgewiesene Restbetrag negativ ist steht jemand gewaltig bei Michael Haupt in den Miesen. Dieser hat diese Tatsache wiederum dem Rechnungsschreiber auch umgehend in einem Brief mitgeteilt:

Der offene Restbetrag ist mit EUR -7,11*10^15 ausgewiesen. Da es sich hierbei um einen negativen Betrag handelt, stehen Sie bei mir in der Schuld. Ich hege Zweifel daran, dass Sie 7,11 Billiarden Euro auf einen Schlag aufbringen können; wir können uns gern auf eine Ratenzahlung einigen.

Generell sollte man sich aus diesem Beispiel mitnehmen, dass bei der Berechnung von Fließkommazahlen Rundungsfehler entstehen können. Das kann man sogar relativ einfach in einem kleinen Beispiel nachstellen:

System.out.println("1.0 - 1.0 = " + new Double(1.0 - 1.0));
System.out.println("1.0 - 0.9 = " + new Double(1.0 - 0.9));
System.out.println("1.0 - 0.8 = " + new Double(1.0 - 0.8));
System.out.println("1.0 - 0.7 = " + new Double(1.0 - 0.7));
System.out.println("1.0 - 0.6 = " + new Double(1.0 - 0.6));
System.out.println("1.0 - 0.5 = " + new Double(1.0 - 0.5));

// Ausgabe:
// 1.0 - 1.0 = 0.0 
// 1.0 - 0.9 = 0.09999999999999998
// 1.0 - 0.8 = 0.19999999999999996
// 1.0 - 0.7 = 0.30000000000000004
// 1.0 - 0.6 = 0.4
// 1.0 - 0.5 = 0.5

In dem Artikel von Michael Haupt wird auch noch auf die Regel 48 aus dem Buch “Effective Java” hingewiesen. Diese lautet “Item 48: Avoid float and double if exact answers are required” (siehe auch im Inhaltsverzeichnis).

Aufgrund dieses Blog Artikels und anderen zuvor zufällig gefundenen positiven Hinweisen auf das Buch “Effective Java” habe ich mir dieses zugelegt um die verschiedenen Empfehlungen mal durchzublättern. In dem besagten Item 48 wird ausführlich auf das Rundungsproblem bei Floats und Doubles eingegangen und unter anderem das folgende sehr schöne Java Schnipsel gezeigt:

double guthaben = 1.00;
int gekaufteTeile = 0;

for (double preis = .10; guthaben >= preis; preis += .10) {
  guthaben -= preis;
  gekaufteTeile++;
  System.out.println("Preis: " + preis);
  System.out.println("Guthaben: " + guthaben);
}
System.out.println("Gekaufte Teile: " + gekaufteTeile);
System.out.println("Restgeld: " + guthaben);

// Ausgaben:
// Preis: 0.1
// Guthaben: 0.9
// Preis: 0.2
// Guthaben: 0.7
// Preis: 0.30000000000000004
// Guthaben: 0.3999999999999999
// Gekaufte Teile: 3
// Restgeld: 0.3999999999999999

In diesem Code Beispiel wird ein Betrag von einem Guthaben abgezogen und mit dem Restbetrag weitergerechnet wobei sich der Preis für ein Teil erhöht. Dabei müsste man mit einem Guthaben von 1.0 und dem Preis und mit dem steigendem Preis von 0.10 exakt 4 Teile kaufen können. Bei der ersten Iteration kostet das Teil 0.1, bei der zweiten 0.2, bei der dritten 0.3 und bei der vierten 0.4. Durch den besagten Rundungsfehler, welcher in dieser Schleife bei der dritten Iteration auftritt, kommt es nicht mehr zum Kauf des vierten Teils. Schlecht für den Verkäufer denn er hat ein Teil weniger verkauft und schlecht für den Käufer denn dieser hat jetzt einen kleineren Betrag als 4.0 am Ende raus (auch wenn die Differenz gegen 0 geht).

Somit gilt ganz allgemein der Hinweis: Entwickelt man eine Finanzsoftware sollte man im eigenen Interesse immer mit BigDecimal, Long oder Integer arbeiten!

Am Ende noch kurz der Hinweis darauf, dass es sich durchaus lohnt das Buch Effective Java einmal durchzublättern bzw. zu kaufen und ordentlich durchzulesen. Man kann sich dadurch einige Probleme ersparen und zudem noch die Qualität des eigenen Codes verbessern.

(via denkspuren)