Erstellen von CSV-Dateien mit Java

In Java bietet sich zum Erstellen von CSV-Dateien die Klasse Super CSV an. Um eine Datei zu erzeugen, benötigt man als erstes einen CSVMapWriter:

CsvMapWriter writer = new CsvMapWriter(new OutputStreamWriter(new FileOutputStream("C:\meineDatei.csv", true),"UTF-8"), CsvPreference.EXCEL_PREFERENCE);

Anstatt mit einem OutputStreamWriter zu arbeiten, kann man auch einen FileWriter verwenden. Da man bei letzterem aber kein Encoding (“UTF-8″) angeben kann und in der Datenbank die Zeichen UTF-8-kodiert sind, müssen wir den Stream verwenden.
Interessant ist der zweite Parameter des FileOutputStream, der angibt, dass die Daten, die eingefügt werden, angehängt werden und nicht vorher gelöscht werden.
Die Einstellung CsvPreference.EXCEL_PREFERENCE legt fest, welche Trennzeichen in der CSV-Datei verwendet werden – wenn man andere Trennzeichen verwenden möchte, muss der später behandelte LOAD DATA INFILE-Befehl angepasst werden.

Als nächstes werden die Textfelder für die CSV-Datei definiert:

final String[] header = new String[] { "id", "name", "adressfeld" };

Unsere Datensätze bestehen also aus 3 Feldern.

Um die CSV-Datei mit Daten zu füllen sind folgende Zeilen notwendig:

final HashMap<String, ? super Object> data = new HashMap<String, Object>();
data.put(header[0], this.id);
data.put(header[1], this.name);
this.adressfeld = this.adressfeld.replace("\\", "\\\\");
data.put(header[2], this.adressfeld);

Die Daten werden in einer HashMap gespeichert und per data.put eingefügt. Was mich etwas überraschte war, dass man das Backslash maskieren muss, ansonsten geht es in der Verarbeitung verloren. Eigenartig, weil man diese Funktionalität sicherlich problemlos in Super CSV hätte integrieren können.

Abschließend werden die Daten dem CSVMapWriter übergeben und dieser wieder geschlossen:

writer.write(data, header);
writer.close();

Und mehrere Datensätze?

Obiges Beispiel ist für einen einzelnen Datensatz, der in einer CSV-Datei gespeichert wird. Wenn man mehrere Datensätze einfügen möchte, müssen sämtliche Schritte (Anlegen eines CSVMapWriter, Daten vorbereiten, Daten einfügen) für jeden Datensatz wiederholt werden.

Den CSVMapWriter 1x anzulegen und am Ende per .close zu schließen, funktioniert nicht – meine Versuche mit der Super CSV-Klasse haben gezeigt, dass dann Datensätze verloren gehen bzw. abgeschnitten werden.

Einlesen der CSV mit LOAD DATA INFILE

Um die so erstellte Datei mit LOAD DATA INFILE in die Datenbank zu importieren, muss folgender Befehl eingetragen werden:

LOAD DATA [LOCAL] INFILE 'C:\\meineDatei.csv'
[REPLACE]
INTO TABLE meine_tabelle
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '\"'
LINES TERMINATED BY '\n'
(id, name, adressfeld);

Vorab: Der Befehl wird so nicht funktionieren, da die Bestandteile innerhalb der eckigen Klammern optional sind:

• LOCAL wird dann angegeben, wenn die CSV-Datei vom Clientprogramm auf dem Clienthost gelesen und an den MySQL-Server geschickt wird. Fehlt LOCAL, liegt die Datei auf dem MySQL-Server
• REPLACE nutzt man, wenn die eingelesene Datei nicht nur neue Datensätze importiert, sondern auch bereits vorhandene überschreibt – also UPDATES durchführt

Alle/Weitere Optionen zu dem LOAD DATA INFILE-Befehl gibt es im MySQL-Handbuch.

Performancevergleich

Ein Performancevergleich ist hier zu finden.

Ich bin ein Gänseblümchen im Sonnenschein
und durch meine Blüte fließt die Sonne in mich rein
Ich bin ein Gänseblümchen und mir wird ganz warm
ich könnt die ganze Welt und dann mich selbst umarmen.
Ich bin ein Gänseblümchen ohne Aggression
Wut, Ärger – was bringt das schon?

Durchatmen, Freakcommander! Momentan gehst du durch die harte Schule einer dir immer noch relativ unbekannten Sprache. Da fällt man mal hin und muss wieder aufstehen, ansonsten wird das nichts.

Die Vorgeschichte

Aber man muss zugegeben, dass der heutige Fehler nicht ganz so leicht zu finden war:

• Ich habe die Klasse Host umgeschrieben. Vorher hat sie einfach per Methode .toDB() ihre Attribute in die Datenbank geschrieben. Nach dem Umschreiben soll sich die Klasse nur dann in die Datenbank schreiben, wenn sie entweder noch nicht in der DB ist oder ein Attribut sich verändert hat und die DB somit aktualisiert werden muss.
  Grund für das Umschreiben: Innerhalb eines Programmaufrufs werden hintereinander Millionen Instanzen erzeugt und geguckt, ob sie sich verändert haben. Wenn das der Fall ist, muss der Eintrag auch in der DB aktualisiert werden. Da aber UPDATE oder INSERT-Befehle teurer sind und nur ein sehr kleiner Teil der Millionen Einträge sich auch wirklich verändern, macht eine Überprüfung, ob ein UPDATE oder INSERT erfolgen muss, definitiv Sinn.
• Wie bin ich vorgegangen?
  1. Eine Methode .getFromDB, die die “alten” Daten aus der DB liest
  2. Eine Methode .equals, die eine Instanz des Objekts mit einer anderen Instanz vergleicht und TRUE zurück gibt, wenn die Attribute gleich sind
  3. Die alte Methode .toDB() dementsprechend angepasst. Einziges Manko war, dass ich in dieser Methode eine Instanz des eigenen Objektes anlegen musste – diese angelegte Instanz des eigenen Objekts bekommt mittels .getFromDB() die alten Daten verabreicht und wird dann mit .equals verglichen.
• Das Anpassen des Quellcodes war schnell erledigt. Das große Problem war nun allerdings, dass die Anwendung jetzt ein Speicherleck hatte. Der benutzte Speicher wuchs und wuchs und endete schließlich in einer Exception.
• Anstatt mich direkt mit dem Code zu beschäftigen und durch auskommentieren und System.out.println-Meldungen dem Problem auf die Schliche zu kommen, beschäftigte ich mich mit der Literaturrecherche zu Memory Leaks, Speicherlecks, Garbage Collector und Eclipse Memory Analyzern oder VisualVM, einem Tool, das eine Realtime Heap-Usage Analyse verspricht.
• Beim Eclipse Memory Analyzer funktionierte das Generieren der .hprof-Datei nicht, die man braucht, um den Analyzer einzusetzen.
• Und die VisualVM ist sicherlich ein tolles Tool, aber mein uralt Notebook, welches zu wenig RAM und CPU-Leistung hat, arbeitet so langsam mit der VisualVM, dass beim Start schon der Java-Prozess mit meiner Anwendung, die den Memory Leak hat, verschwunden war. So konnte ich leider keinen Memory-Monitorer einschalten oder den Heap dumpen.. No chance.
• Und nach stundenlanger Recherche und antesten etlicher Tools, um einem Speicherleck in Java zu begegnen, bekam ich schon wieder dieses Gefühl: Wie kann es sein, dass eine Programmiersprache, die millionenfach eingesetzt wird, kein einfach zu installierendes Tool hat, welches automatisch die Daten sammelt, um einem dann vorzuschlagen, welche Klassen oder Methoden man sich nochmal genauer anschauen sollte, um das Speicherleck zu schließen. Wenn in Foren ein Programmierer Probleme mit einem Tool hat, wird ihm einfach ein anderes Tool empfohlen, welches ähnlich ist und bei ihm laufen sollte. Na ja, ich hatte keinen Bock mehr mich durch irgendwelche Seiten und Tools zu klicken.
• Das Problem war an irgendeiner Stelle in meinem Code, also finde ich einfach die Stelle und behebe das Problem.
• Nachdem ich sichergestellt hatte, dass sämtliche Statements, PreparedStatements, ResultSets und Connections nach getaner Arbeit auch wieder geschlossen wurden und das Problem nach wie vor auftrat, kümmerte ich mich um die Instanz, die innerhalb der .toDB()-Methode erzeugt wird. Vielleicht werden ganz viele Instanzen erzeugt, die der Garbage Collector aus irgendwelchen Gründen nicht löschen kann. Aber auch daran lag es nicht.
• Schließlich ging ich dazu über ganze Funktionen und Programmteile auszukommentieren. Folgender Programmcode verursachte das Speicherleck

Der Fehler

In der Methode .getFromDB(), die einfach nur per DB-Query Daten einliest, gab es folgende 3 Zeilen Code, die Grund für das Memory Leak waren:

this.setM_swap(rs.getInt(16));
this.setD_total(rs.getInt(17));
this.setD_free(rs.getInt(18));

Aus dem ResultSet der DB-Abfrage werden per Setter-Methoden die Attribute gesetzt. Das Problem? Da die Java-Datentypen und die DB-Felder für m_swap, d_total und d_free mit Integer bzw. int nicht ausreichend lang waren, habe ich sie nachträglich auf long bzw. Bigint (DB) geändert. Dabei habe ich auch die setter wie setM_swap() so geändert, dass sie als Parameter long erwarten.  Normalerweise schreit ja gleich das IDE los, wenn ein Typ nicht passt, aber Java findet (und in diesem Fall völlig zu Recht), dass Methoden, die long als Parameter erwarten, auch mit int gefüttert werden können und hat deswegen nicht gemeckert.

Das Memory Leak kann ich mir nur so erklären, dass mit rs.getInt auf eine Spalte zugegriffen wurde, welche in der Datenbank als BigInteger definiert ist.

Richtigerweise hätte man mit rs.getLong() arbeiten müssen, dann gibt es auch keine Probleme mit dem Speicher. ;)

class Erde{
var $name;
var $groesse;
var $avgEntfernungZurSonne;
var $bevoelkerung;
...

function __construct(...) {
...
}

function eineFkt(...) {
...
}
}

Nun habe ich noch eine Klasse Sonnensystem. Und diese Klasse soll als Attribute die einzelnen Planeten beinhalten, also:

class Sonnensystem{
var $erde;
var $venus;
var $mars;
...

function __construct($erde, $venus,...) {
$this->erde = $erde;
$this->venus = $venus;
...
}

function gebReihenfolgeDerPlanetenAbSonne() {
$arrayEntfernung =
($this->erde->name => $this->erde->avgEntfernungZurSonne,
$this->venus->name => $this->venus->avgEntfernungZurSonne,
...) ;
...
}
}

Das Problem ist jetzt, dass NetBeans in Sonnensystem::gebReihenfolgeDerPlanetenAbSonne() nicht weiß, von welchem Typ die Variablen $this->erde und $this->venus sind. Denn die werden ja nirgendwo genauer in der Klasse Sonnensystem spezifiziert. Folglich kann mir NetBeans auch nicht vorschlagen, welche Attribute/Methoden ich bei $this->erde aufrufen möchte. Das finde ich allerdings extrem schwach, denn genau deswegen setze ich ja ein IDE ein.

Mir sind zwar bei Recherchen Schlagwörter wie z.B. Typehinting über den Weg gelaufen, aber das könnte ich ja nur im Konstruktor einsetzen und dann wäre nur dort sicher gestellt, dass $erde eine Instanz der Klasse Erde ist und hilft folglich nicht wirklich weiter.

Also, mal konkretisiert: Wie kann ich in PHP festlegen, dass ein Attribut von einem bestimmten Typ ist. So zumindest nicht:

class Sonnensystem{
var Erde $erde;
...

Update + Update + Update + Update
Damit die IDE NetBeans weiß, von welchem Typ ein Klassen-Attribut ist, muss man PHPDoc-Kommentare verwenden:

class Sonnensystem{
/**
* @var Erde
**/
private $erde;
...

Felix schlug dann noch vor, das Attribut auf “private” zu setzen und dann im Konstruktor mit TypeHinting zu arbeiten. Das funktionierte bei mir in NetBeans allerdings nicht. Da scheint es also Unterschiede zwischen den IDEs zu geben.