# Ini-Klasse Datenverwaltung



## TheWhiteShadow (27. Feb 2012)

Hallo zusammen,

Zunächst einmal, ich will nichts von Properties hören.

Ich habe eine Ini-Klasse geschrieben, welche zum Auslesen von Ini-Dateien auch wunderbar funktioniert.
Jetzt muss ich aber auch in die Dateien schreiben. Allerdings zerstört die bisherige Implementation das Format, da ich die Daten in einer HashMap abgelegt habe und somit keinerlei Strukturinformationen aufbeware.
Jetzt habe ich überlegt, die Daten in einer ArrayList zu speichern, die die Daten Zeilenorientiert speichert. (Bzw entspricht das eher einem kleinen Tree)
Somit lässt sich der Urzustand weitgehen wieder herstellen.
Diese Variante ist natürlich langsamer als über eine HashMap und das wirkt sich bei jedem Zugriff auf die Daten aus.
Somit habe ich mir gedacht, beide Varianten gleichzeitig zu speichern. Dabei hatte ich allerdings ein Synchronisationsproblem, und mich letztendlich dagegen entschieden.
zuletzt kam mir die Idee, die Datei beim Schreiben neu auszulesen und darüber, die Struktur mit den neuen Daten zu erweitern und wieder zu schreiben. Sollte bei einem lese- und einem Schreibvorgang innerhalb der Anwendung ok sein, denke ich.

Ich fass noch mal zusammen:
Hashmap
ArrayList
beides
Hashmap + Neuauslesen fürs Schreiben.

Was würdet ihr mir empfehlen, oder habt ihr ne bessere Lösung?


----------



## Gast2 (27. Feb 2012)

Musst du das alles komplett selbst implementieren? Das gibts doch alles schon fertig 
[ini4j] - Java API for handling Windows ini file format
Java Configuration API

Oder gibts bestimmte Gründe warum du das selbst nachbauen willst?


----------



## irgendjemand (27. Feb 2012)

oder mal anderst : was ist der grund warum du eben nicht das java-eigene format *properties* verwenden willst ?


----------



## Gast2 (27. Feb 2012)

EikeB hat gesagt.:


> Musst du das alles komplett selbst implementieren? Das gibts doch alles schon fertig
> [ini4j] - Java API for handling Windows ini file format
> Java Configuration API



Absolut zustimm! Verwende das framework auch. Großer Vorteil: Es implementiert auch das Preferences Interface. d.h. du musst deine Applikation nicht auf die API der INI Files auslegen und kannst somit den bakcingstore auch zu was anderem ändern. 



irgendjemand hat gesagt.:


> oder mal anderst : was ist der grund warum du eben nicht das java-eigene format *properties* verwenden willst ?


Dafür kanns 100000000 Gründe geben, z.B. dass man mit properties ausschließlich Strings speichern kann (oder man für die Konvertierung selber sorgen muss), oder man in properties keine hierarchische Struktur hat, oder , oder, oder


----------



## faetzminator (27. Feb 2012)

kappesf hat gesagt.:


> Dafür kanns 100000000 Gründe geben, z.B. dass man mit properties ausschließlich Strings speichern kann (oder man für die Konvertierung selber sorgen muss), oder man in properties keine hierarchische Struktur hat, oder , oder, oder



Wieso, das kann ich doch mit wenig Aufwand nachbauen, indem ich einfach [c]foo.bar.baz[/c], [c]foo.bar.quoz[/c] etc. verwende und mir eine Hilfsmethode [c]readProperty(String... path)[/c] schreibe.


----------



## bygones (27. Feb 2012)

faetzminator hat gesagt.:


> Wieso, das kann ich doch mit wenig Aufwand nachbauen, indem ich einfach [c]foo.bar.baz[/c], [c]foo.bar.quoz[/c] etc. verwende und mir eine Hilfsmethode [c]readProperty(String... path)[/c] schreibe.



properties sind nicht ausgelegt strukturierte Daten zu repraesentieren. Sie da reinzuzwingen ist unsinn. Und wie du sagst "nachbauen". Warum nachbauen, wenn man es anderswo ohne das zu bekommen hat....

wuerdest du eine komplexere XML struktur mit Bedacht als Properties repraesentieren ?

Ich bin momentan Fan von YAML - weil fuer meine Daten Properties nicht taugen und XML in Java mehr als besch*** ist


----------



## TheWhiteShadow (27. Feb 2012)

ini4j hab ich mal probiert, ist zwar ganz nett, schafft es aber auch nicht die Kommentare bei zu behalten, außerdem stören mich die Konvertierung von Umlauten, wodurch die Datei nicht mehr richtig lesbar wird. Kann man vielleicht einstellen, aber bevor ich mich stundenlang da rein arbeite schreib ich lieber was eigenes.

Ich brauch auch keine großartige Hirachie. Die Einteilung in Sectionen reicht völlig aus.


----------



## Empire Phoenix (27. Feb 2012)

Warum nicht einfach die java interne xml krams nehmen? solange getter und Setter ordentlich geschreiben sind sollte das ja kein problem machen. Und damit kann man dann wirklich mit einem 1 zeiler laden und schreiben und zwar auch verschachtelte objecte und sonstwas.


----------



## Gast2 (27. Feb 2012)

Empire Phoenix hat gesagt.:


> Warum nicht einfach die java interne xml krams nehmen? solange getter und Setter ordentlich geschreiben sind sollte das ja kein problem machen. Und damit kann man dann wirklich mit einem 1 zeiler laden und schreiben und zwar auch verschachtelte objecte und sonstwas.



Das wäre dann auch mein Alternativer Vorschlag.


----------



## faetzminator (27. Feb 2012)

bygones hat gesagt.:


> wuerdest du eine komplexere XML struktur mit Bedacht als Properties repraesentieren ?


Nö, aber dafür würde ich auch kein INI nehmen  Für den normalen Anwendungsfall (von INI u/o properties) sehe ich schlichtwegs keinen Vorteil von INI gegenüber Properties.
Ansonsten natürlich XML.



Empire Phoenix hat gesagt.:


> Warum nicht einfach die java interne xml krams nehmen?



Ich würde JDOM empfehlen, eine bessere XML Lib kenne ich nicht. Sehr einfach zu verwenden.


----------



## parabool (27. Feb 2012)

> da ich die Daten in einer HashMap abgelegt habe und somit keinerlei Strukturinformationen aufbeware.
> Jetzt habe ich überlegt, die Daten in einer ArrayList zu speichern, die die Daten Zeilenorientiert speichert.



Bei einer LinkedHashMap bleibt die Reihenfolge der Einträge erhalten.


----------



## bygones (27. Feb 2012)

faetzminator hat gesagt.:


> Nö, aber dafür würde ich auch kein INI nehmen  Für den normalen Anwendungsfall (von INI u/o properties) sehe ich schlichtwegs keinen Vorteil von INI gegenüber Properties.
> Ansonsten natürlich XML.
> Ich würde JDOM empfehlen, eine bessere XML Lib kenne ich nicht. Sehr einfach zu verwenden.


ebenso schrecklich in meinen augen... da lieber YAML mit snakeyaml oder aehnlichem... aber geschmackssache natuerlich


----------



## TheWhiteShadow (27. Feb 2012)

LinkedHashMap, klingt vom Namen her total dämlich.

Ich hab zwar ein XML-Parser (XStream), aber ich wollte damit nicht meine Configuration-Datei so sperrig machen.
Und Yaml muss jetzt nicht auch noch sein. Der Parser funktioniert ja schon super.

Habs noch mal mit Option 3 probiert und klappt auch ganz gut, wenn ich die Daten noch mal kapsel und die Zeilennummer mitspeichere.


----------



## delphiking1980 (28. Feb 2012)

es dauert zwar bis man sich so richtig eingefuchst hat aber dann ist es ein selbstläufer und was gibt es besseres in der OOP als mit diesen Objekten zu arbeiten so hast du alles was du möchtest in einem Objekt gespeichert in einem format wie du es möchtest.


----------



## TheWhiteShadow (28. Feb 2012)

Wie schon gesagt, es ist ne Config-Datei.
Die Objekte, die ich speichern möchte sind nur Pfade und Namen, manchmal auch Zahlen. Und da sind Strings irgendwie ganz passend. ^^


----------

