Wer stand noch nicht vor dem Problem das “Allheilmittel”-Format XML parsen zu müssen?
Allein das Implementieren des DOM-Parsers war immer schon ein Aufwand, der zumindest mich immer davon abgeschreckt hatte. Wenn das alleine aber schon nicht genug gewesen wäre, wollen die Werte ja auch weiterverarbeitet werden. D.h. es muss noch ein Mapper geschrieben werden. Aufwand über Aufwand…
Doch wie so oft, ist ein “Retter in weißer Rüstung” zur Hilfe geeilt. Nachdem mehrere “Prinzen”, wie JAXB auf den Plan getreten sind, erschien letztens noch einer: XStream. Eine Bibliothek mit der XML-Mapping in beide Richtungen mit wenigen Zeilen möglich ist. Insbesondere das Einlesen ist extrem einfach.
<person>
<firstname>Joe</firstname>
<lastname>Walnes</lastname>
<phone>
<code>123</code>
<number>1234-456</number>
</phone>
<fax>
<code>123</code>
<number>9999-999</number>
</fax>
</person>
Person newJoe = (Person)xstream.fromXML(xml);
Und schon hat man sein Objekt. Hierbei sollte man jedoch Vorsicht walten lassen. Xstream ruft standardmäßig keinen Konstruktor auf. Das bedeutet, eigene Variablen, die nicht in der XML-Datei stehen werden gegebenenfalls nicht initialisiert. Wer darauf angewiesen ist, muss einen eigenen Converter registrieren.
Das Schreiben mit XStream ist ebenso einfach, wenngleich nicht so elegant. Vor allem bei Klassen, die viele Hilfsfelder haben, müssen diese mittels omitField von der Serialisierung ausgeklammert werden. Ein transient vor dem Attribut hilft da glücklicherweise. Es sei hier angemerkt, dass auf Feldebene gearbeitet wird. Man kann also keine Felder “verstecken”, da auch vor private nicht Halt gemacht wird.
Hier wäre die Möglichkeit schön, alternativ alle Felder auszuschalten und nur explizit Felder freigeben zu können. Alternativ wäre interessant eher über die öffentlichen Zugriffsmethoden zu gehen.
Ebenfalls ist noch keine Vererbungsprüfung möglich. D.h. wenn ich gleiche Felder in verschiedenen Subklassen existieren, muss jede Subklasse einzeln behandelt werden, was es insbesondere bei Plugin-Architekturen schwierig macht, da dort die Subklassen nicht immer bekannt sind.
Zusammenfassend würde ich sagen, dass XStream ein netter Anfang ist, aber noch einiges an Optimierungspotenzial enthält.