Java Preferences API oder lieber doch nicht?

  • Themenstarter Themenstarter Gast2
  • Beginndatum Beginndatum
G

Gast2

Gast
Hallo,

auch wenn es zu dem Thema schon ein paar Threads gibt bin ich immer noch unschlüssig.

Ich stehen gerade davor die Programm Einstellungen meiner Software speichern zu müssen.
Ich weiss auch, dass es die Preferences API gibt und, dass diese Einstellungen je nach Betriebssystem in z.B. Registry oder xml Dateien speichert.

Mir wäre es aus dem Bauch heraus eigentlich lieber, dass die Einstellungen IMMER im Home Verzeichnis des Nutzers landen. Würde aber andererseits gerne die komfortable Preferences API nutzen.

Der größte Knackpunkt wäre meiner Meinung nach: Wie kann ich auf einfachste Weise ALLE Einstellungen aus der z.B. Registry wieder löschen falls ich das möchte? Bin eigentlich eher ein Linux Nutzer und kenne mich daher mit Registry nicht so gut aus. Mir erscheint dieser Punkt recht komplex.

Was meint ihr denn so dazu?
Was nutzt ihr selber?
Gibt es noch echte Alternativen? (Keine Properties API)

Schon mal vielen Dank!
 
Ich habe schon oft [ini4j] - Java API for handling Windows ini file format verwendet. Besonders wenn der User auch mal "per Hand" ein paar Konfigurationseinstellungen verändern will.
Da hast du alles kategorisiert und schön leserlich.
Das configfile kannst du auch ohne probleme ins homeverzeichnis des users legen.

EDIT:
sehe grad dass Apache Configurations das auch kann 😉
 
Zuletzt bearbeitet von einem Moderator:
Ich habe für ewigen Zeiten mal eine eigene Preferences-Implementierung geschrieben. Das war ziemlich simpel. Die Einbindung klappt - glaube ich - über einen Parameter beim startup, aber das ist sicher dokumentiert. Diese Preferences-Implementierung tut natürlich nicht das, was du dir wünschst, betrachte sie einfach als Beispiel:

Java:
package de.tobiasdemuth.common.tool;

import java.util.prefs.Preferences;
import java.util.prefs.PreferencesFactory;

/**
 * Produces InMemoryPreferences.
 * 
 * @author Tobias Demuth >mailto:myself@tobiasdemuth.de<
 */
public class InMemoryPreferencesFactory implements PreferencesFactory {

	private static final Preferences sysRoot = new InMemoryPreferences(null, "");

	private static final Preferences usrRoot = new InMemoryPreferences(null, "");

	/**
	 * @see java.util.prefs.PreferencesFactory#systemRoot()
	 */
	public Preferences systemRoot() {
		return sysRoot;
	}

	/**
	 * @see java.util.prefs.PreferencesFactory#userRoot()
	 */
	public Preferences userRoot() {
		return usrRoot;
	}

}

Java:
package de.tobiasdemuth.common.tool;

import java.util.HashMap;
import java.util.Map;
import java.util.prefs.AbstractPreferences;
import java.util.prefs.BackingStoreException;

/**
 * A Preferences-implementation that stores it preferences in-memory. Useful for
 * testing purposes.
 * 
 * @author Tobias Demuth >mailto:myself@tobiasdemuth.de<
 */
public class InMemoryPreferences extends AbstractPreferences {

	/**
	 * The preferences (key-value-pairs) at this node.
	 */
	private Map<String, String> preferences;

	/**
	 * The children (sub-nodes) of this node.
	 */
	private Map<String, AbstractPreferences> children;

	/**
	 * Constructs a new InMemoryPreferences-instance. Called directly only by
	 * InMemoryPreferencesFactory and InMemoryPreferences.
	 * 
	 * @param parent
	 *            the parent node
	 * @param name
	 *            the node's name
	 */
	InMemoryPreferences(AbstractPreferences parent, String name) {
		super(parent, name);

		preferences = new HashMap<String, String>();
		children = new HashMap<String, AbstractPreferences>();
	}

	/**
	 * Checks the children map if the required node exists. If the node exists
	 * it will be returned, otherwise it will be created.
	 * 
	 * @see java.util.prefs.AbstractPreferences#childSpi(java.lang.String)
	 */
	@Override
	protected AbstractPreferences childSpi(String name) {
		if (!children.containsKey(name)) {
			children.put(name, new InMemoryPreferences(this, name));
		}
		return children.get(name);
	}

	/**
	 * @see java.util.prefs.AbstractPreferences#childrenNamesSpi()
	 */
	@Override
	protected String[] childrenNamesSpi() throws BackingStoreException {
		String[] array = new String[children.size()];
		return children.keySet().toArray(array);
	}

	/**
	 * Not needed, because instances of InMemoryPreferences are not backed by
	 * any BackingStore.
	 * 
	 * @see java.util.prefs.AbstractPreferences#flushSpi()
	 */
	@Override
	protected void flushSpi() throws BackingStoreException {
	}

	/**
	 * @see java.util.prefs.AbstractPreferences#getSpi(java.lang.String)
	 */
	@Override
	protected String getSpi(String key) {
		return preferences.get(key);
	}

	/**
	 * @see java.util.prefs.AbstractPreferences#keysSpi()
	 */
	@Override
	protected String[] keysSpi() throws BackingStoreException {
		String[] array = new String[preferences.size()];
		return preferences.keySet().toArray(array);
	}

	/**
	 * @see java.util.prefs.AbstractPreferences#putSpi(java.lang.String,
	 *      java.lang.String)
	 */
	@Override
	protected void putSpi(String key, String value) {
		preferences.put(key, value);
	}

	/**
	 * Removes this node from it's parent's children-list and clears the
	 * Preferences at this node.
	 * 
	 * @see java.util.prefs.AbstractPreferences#removeNodeSpi()
	 */
	@Override
	protected void removeNodeSpi() throws BackingStoreException {
		InMemoryPreferences parent = (InMemoryPreferences) super.parent();
		if (parent != null) {
			parent.removeChild(name());
		}
		preferences.clear();
	}

	/**
	 * @see java.util.prefs.AbstractPreferences#removeSpi(java.lang.String)
	 */
	@Override
	protected void removeSpi(String key) {
		preferences.remove(key);
	}

	/**
	 * Not needed, because instances of InMemoryPreferences are not backed by
	 * any BackingStore.
	 * 
	 * @see java.util.prefs.AbstractPreferences#syncSpi()
	 */
	@Override
	protected void syncSpi() throws BackingStoreException {
	}

	/**
	 * Removes the child with the given name from the children-list. If no such
	 * child exists, nothing happens.
	 * 
	 * @param name
	 *            the name of the child to remove.
	 */
	void removeChild(String name) {
		children.remove(name);
	}

}
 
Ein Gedanke wäre noch, die Einstellungen in einem Objekt zu halten und per XSteam als XML File im User Ordner abzulegen. Leider kann ich wenig dazu sagen, wie es reagiert, wenn User das File editieren und dabei Unsinn baut. Alternativ hat man mit db4o eine Objektdatenbank, die sich auch gut dazu eignet mal schnell Objekte in ein File zu legen ... aber für den User nicht ohne weiteres einsehbar.

Vorteil bei beiden (in deinem Fall, weil du es benötigst) ... löschen des Files ... alle Einstellungen weg.
 
Übrigens, warum willst du unbedingt die Registry unter Windows verwenden? Nur weil sie da ist, muss man sie nicht nehmen. Ich habe sie bisher nicht vermisst und meine Usereinstellungen immer im User Verzeichnis und Systemspezifische Einstellungen im Programmordner abgelegt.
 
Übrigens, warum willst du unbedingt die Registry unter Windows verwenden? Nur weil sie da ist, muss man sie nicht nehmen. Ich habe sie bisher nicht vermisst und meine Usereinstellungen immer im User Verzeichnis und Systemspezifische Einstellungen im Programmordner abgelegt.

:autsch: Ich hab geschrieben, dass ich die Registry ja eben NICHT benutzen will...
 
🙂 Nix für ungut, ich dachte, da du das Wort "Registry" 3 mal in deinem Post verwendet hast, fand ich es erwähnenswert, dass du auch in der Windowswelt darauf verzichten kannst. Habe mich vielleicht etwas komisch ausgedrückt.
 
Nachdem die Frage von Dir schon ein paar mal gestellt wurde: Wieso implmentierst Du nicht eine eigene kleine Preferences-Klasse, die im Wesentlichen auf einer Hashmap beruht und getter uns sette für die von Dir benötigen Einstellungen hat? Speichern kannst Du es per ObjectOutputstream binär (oder mit XMLEncoder als xml) und bei Programmstart liest Du es jeweils ein. Speicherort sollte ein Ort irgendwo in User.Home sein. Auf diese Weise hast Du alle Sachen, die Du brauchst, entsprechend Deiner Bedürfnisse. Die Implementierung sollte kaum eine Stunde in Anspruch nehmen.
 

Zurück
Oben