Sinn von XML in Java

[Morgyr]

Hallo.

Ich habe mich vor kurzem mit XML und anschließend mit Object Serialization und Preferences beschäftigt.
So nehme ich zumindest mal an, dass es wohl ein Sinn hat, extra Klasse und Methoden bereizustellen, um XML-Dateien zu verwalten.

Doch in einem gut geschriebenen (und vor allem auch größerem) Programm, dürfte XML doch kaum noch Sinn machen. So sollte (meiner Meinung nach) zumindest dafür gesorgt werden, dass alle Werte dort sind, wo sie hingehören und das sind nun mal die Klassen. Diese ließen sich also zum Speichern, ohne irgendwelche zusätzlichen Initialisierungen, serialisieren.

Für Konfigurationen, habe ich letztlich dann die Möglichkeit auf die Preferences zurückzugreifen, sprich mit Registry und den Gegenstücken dieser zu arbeiten. (Das setzt selbstverständlich voraus, dass man das Programm deinstallieren können muss.)

Letztlich habe ich durch die zwei Methoden den Vorteil, dass ein User, der sich mit XML nicht auskennt, auch nicht die Möglichkeit hat, etwas manuell zu verändern. Sozusagen als Schutz davor irgendwelche relevanten Werte zu ändern.
Wenn ich dem User die Möglichkeit geben möchte, die Konfiguration einzusehen, dann baue ich ihm eine GUI, die diese ausgibt. Wenn es unnötig ist, diese einzusehen, dann wird der User merken, dass er es nicht kann, es sei denn er kennt sich ausreichend mit der Registry(oder eben den Gegenstücken) aus oder kann unlesbaren Code lesen.

Also zu der Frage: Wieso soll ich noch XML in Java benutzen und damit erstmal komplexe Methode schreiben, die mir Variablen-Werte meiner Klasse in XML-Werte mit zugehörigem Tag umwandeln?

Mit freundlichen Grüßen
Morgyr

 

[pinhead84]

Also zu der Frage: Wieso soll ich noch XML in Java benutzen und damit erstmal komplexe Methode schreiben, die mir Variablen-Werte meiner Klasse in XML-Werte mit zugehörigem Tag umwandeln?

Spätestens wenn deine Daten die JVM verlassen, kann kaum ein externes Programm noch etwas mit deinem serialisierten Output etwas anfangen. XML dagegen ist unabhängig von Betriebssystem und Programmiersprache.

Wenn ich dem User die Möglichkeit geben möchte, die Konfiguration einzusehen, dann baue ich ihm eine GUI, die diese ausgibt.

Wie nobel von dir. In vielen Fällen kann oder will man aber auf eine GUI verzichten. Ich lobe mir z.B. die XML-Konfigurationen von Tomcat. Mit einem anständigen XML-Editor kann man besser damit arbeiten, als jede GUI es darstellen könnte. (vorausgesetzt man weiß, was man tut)

 

[Morgyr]

Gut, zu dem ersten gebe ich dir recht. Nur rechtfertigt das, meiner Meinung nach, keine zusätzlichen XML-Klasse, dafür kann ich mir nicht genug Fälle ausdenken, in denen das sinnvoll ist. Wenn ich es dort anwende, muss auch die andere Sprache in der Lage sein, eine solche Datei zu verarbeiten. Klar, die zu verarbeiten ist letztlich kein großes Ding, aber dabei noch auf irgendwelche Schemata oder DTD zu achten und das ganze wohlgeformt zu gestalten, macht das ganze komplex, und in dem Sinn kann es dann schon wieder die Wahlmöglichkeit geben, für ein paar Daten ein eigenes Format zu erstellen, eben je nach Aufwand/Zweck.


Wozu muss ein User(als Enduser) wissen, was in der XML steht? Geschweige denn, welcher ganz normale User hat einen XML-Editor installiert? Das Resultat wird er sehen, wenn er was ändern oder erstmal lesen möchte, geht er in den Optionen-Bereich. Für einen Enduser reicht das. Und vor allem, er weiß eben oft nicht, was er tut.

 

[Beni]

Schemata, DTD?: niemand zwingt dich dies zu erstellen oder zu prüfen. Es ist natürlich schön wenn es eine Dokumentation des Formates gibt... aber auch eine XML-Datei ohne diese Dinge wird von einem externen Programm besser verarbeitet als eine Serialisierungs-Datei.

Gibt es externe Programme?: Bist du sicher, dass dein Programm nie durch eine Version 2 ersetzt wird? Du weisst nicht was Version 2 sein wird (und welche Sprache dafür verwendet wird). Oder ein OpenSource-Programmierer findet deine Dateien toll, nicht aber dein Programm und baut sich deshalb selber ein neues. So wie z.B. MS Office vs. OpenOffice.

Noch ein Argument: XML ist extrem flexibel. Wenn du mal deine Klassenhierarchie umbauen musst, Felder löschst, umbenennst und hinzufügst, dann wird eine Serialisierungs-Datei irgendwann um die Ohren fliegen. Eine XML-Datei wirst du immer lesen können und auch verschiedene Versionen wild mischen.

 

[Wildcard]

Serialisierung ist keine Persistierung. Viel zu unflexiblel, viel zu anfällig. Wird eigentlich nur benutzt um Daten über ein Socket zu schießen, oder ins Clipboard zu transferieren.

Also zu der Frage: Wieso soll ich noch XML in Java benutzen und damit erstmal komplexe Methode schreiben, die mir Variablen-Werte meiner Klasse in XML-Werte mit zugehörigem Tag umwandeln?

Komplexe Methode schreiben?
Wenn ich XML verwende, dann mit einem XML Binding Framework (vorzugsweise EMF). Ich erstelle das Metamodell (z.B. als XML Schema, oder UML Diagramm) und das Binding-Framework erstellt die passenden Java Klassen. Damit ist XML auf Java Objekte abgebildet und ich habe mir jede Menge Code für das Modell gespart.
Bei EMF lässt sich das Modell zusätzlich noch auf Hibernate und Konsorten mappen, der Objektbaum bringt eine vollständige Notification Schnittstelle mit, ist Undo-/Redo fähig, unterstützt SQL-Queries, Transaktionen inkl. Roll-Back, lässt sich mit einem generischen Differentiator vergleichen, lässt sich zur Runtime Reflection-Basiert beliebig erweitern, ...

 

[pinhead84]

@Wildcard: EMF hört sich interessant an. Kann man das auch unabhängig von Eclipse verwenden?

 

[Wildcard]

@Wildcard: EMF hört sich interessant an. Kann man das auch unabhängig von Eclipse verwenden?

Ja, allerdings mit etwas weniger Features. Du kannst den Eclipse Compare Editor nicht verwenden und du kannst dir keinen fertigen Editor generieren lassen. Das Modell selbst und der optionale Edit Code zum Anzeigen und Manipulieren des Modells sind jedoch Eclipse Unabhängig, du musst lediglich ein jar einbinden.

 

[Morgyr]

Oje. Ich habe wohl eine wichtige Sache vergessen.
Wenn ich ein Objekt serialisiere, anschließend in meinem Programm der Klasse meines Objekts irgendwelche Variablen und Methode ändere/hinzufüge/lösche und dann versuche, das Objekt zu laden, dann bekomme ich eine Exception (ClassNotFoundException?)?
Wenn ja, wäre das selbstverständlich fatal. Das habe ich vollkommen übersehen.

Das es sowas wie EMF gibt, wusste ich nicht. ICh werde mir das mal angucken.

 

[Grasstampfer]

Oje. Ich habe wohl eine wichtige Sache vergessen.
Wenn ich ein Objekt serialisiere, anschließend in meinem Programm der Klasse meines Objekts irgendwelche Variablen und Methode ändere/hinzufüge/lösche und dann versuche, das Objekt zu laden, dann bekomme ich eine Exception (ClassNotFoundException?)?
Wenn ja, wäre das selbstverständlich fatal. Das habe ich vollkommen übersehen

daher wird man vom compiler (jedenfalls von eclipse ;-) ) ab 1.5 gewarnt, wenn man nicht die serialversionuid gesetzt hat...

 

[HoaX]

wenn keine da ist generiert der kompiler eine. solang man nicht selbst in read/writeObject rumfummelt kann die eigentlich gefahrlos weggelassen werden

 

[Morgyr]

Gut. Ihr habt mich überzeugt.
Danke euch allen