[Java] Plattformunabhängig Installationsverzeichnis speichern (o.ä.)

[drunken monkey]

Ich bräuchte mal wieder Hilfe bei Java, diesmal geht's um Plattformunabhängigkeit. Ich verwende nämlich zur Konfiguration eines meiner Programme eine .ini-Datei, die auch vom Benutzer selbst editiert werden können soll (logisch). Da das Programm allerdings dafür gedacht ist, von überall aus gestartet werden zu können, habe ich ein kleines Problem damit, wie ich diese ini-Datei finde. Denn wenn man sie einfach in dem Ordner erstellen würde, in dem auch das Projekt liegt, müsste das Programm ja irgendwie in Erfahrung bringen, wo das auf dem konkreten System jetzt ist, und dazu ist mir bisher enfach kein plattformunabhängiger Weg eingefallen.
Ich hab's jetzt so gemacht, dass sich das Programm per "File.listRoots()" alle Wurzelverzeichnisse holt und eins davon als Standort der Datei aussucht, in das sie der Benutzer dann kopieren muss, aber offensichtlich ist das eher umständlich und zwingt vor allem den Benutzer zu einer bestimmten Lage, die er in den meisten Fällen wohl nicht gewählt hat.
Ich hab's auch schon damit versucht, es per "System.setProperty()" zu speichern, aber das merkt er sich anscheinend wiederum nicht. <___<'

So, ich hoffe, es ist halbwegs verständlich, was ich will. Kann mir da irgendwer helfen?


Ahja, das Ganze ist nicht fürs Tamagotchi-Projekt, daran setze ich mich erst in den Ferien. Nur, falls hier besondere Ehrgeizler rumlaufen.

[Jesus_666]

Gute Frage. AFAIK mußt du das aber für jede Plattform einzeln einstellen (also ~/.myapp.ini unter Linux/BSD, ~/Library/Preferences/myapp.ini unter OS X* und %APPDATA%\myapp\myapp.ini unter Windows).

Du kannst zwar auch generell mit ~/.myapp.ini arbeiten und unter Windows ~ mit %APPDATA% zu ersetzen, aber das ist auch wieder suboptimal.


* Unter OS X ist es in ~/Library/Preferences oft üblich, den kompletten Klassennamen anzugeben, also beispielsweise ~/Library/Preferences/org.dm.myapp.ini. Das ist aber nur eine Konvention und keineswegs erforderlich.

[Ineluki]

gibt es denn das gute alte argv[0] nicht mehr, in dem der name des ausgefuehrten Programms samt Pfad steht ?

[drunken monkey]

Gute Frage. AFAIK mußt du das aber für jede Plattform einzeln einstellen (also ~/.myapp.ini unter Linux/BSD, ~/Library/Preferences/myapp.ini unter OS X* und %APPDATA%\myapp\myapp.ini unter Windows).

...

Mist, das hatte ich befürchtet. :-/
Naja, kann man nichts machen, ist's halt etwas unsauber. ^^''

Edit: Hm, bist du sicher, dass das auch mit Java klappt? Oder ist der folgende Code dafür falsch?

Code:

private static final File INI_DEST = new File("%APPDATA%\\commands.ini");

gibt es denn das gute alte argv[0] nicht mehr, in dem der name des ausgefuehrten Programms samt Pfad steht ?

...

Unter Java? o_O'' Wüsste nicht, dass es das jemals gegeben hätte.
Und selbst bei C steht da ja afaik nur der Kommandostring drin, also wenn's im Path ist und daher aus einem anderen Verzeichnis geholt wurde, kann man das dort auch nicht so herausfinden.

[wry]

@drunken monkey
Würde es nicht reichen wenn die Datei im selben Verzeichnis, indem auch das Programm liegt, abgespeichert bzw. erstellt würde? Man könnte dann ja imo zb so drauf zugreifen:

Code:

private static final File INI_DEST = new File("commands.ini");

Aber ich glaube ich versteh die Frage nichtmal richtig

[Crash-Override]

@drunken monkey
Würde es nicht reichen wenn die Datei im selben Verzeichnis, indem auch das Programm liegt, abgespeichert bzw. erstellt würde? Man könnte dann ja imo zb so drauf zugreifen:

Code:

private static final File INI_DEST = new File("commands.ini");

Aber ich glaube ich versteh die Frage nichtmal richtig

...

Das dürfte aber die Datei (soweit ich das von Delphi weiß) im Path-Verzeichnis des 0-Arguments ablegen also wenn du ne Verknüfung anlegst und beim Ausführungspfad "C" angibst wird es unter C erstellt. Nur wenn du die Datei per Doppelklick öffnest ginge es so. Außerdem würde kein vernünftiger nicht-XP-Nutzer auf so eine Idee haben, da du in keinem System abgesehen von XP (und niedriger) Schreibrechte im Anwendungsverzeichnis haben solltest (außer das System ist schlecht konfiguriert oder du hast die Anwendung z.B. auf dem Desktop).

[Jesus_666]

Edit: Hm, bist du sicher, dass das auch mit Java klappt? Oder ist der folgende Code dafür falsch?

Code:

private static final File INI_DEST = new File("%APPDATA%\\commands.ini");

...

Ich weiß nicht, ob Java in der Lage ist, Windows-Variablen aufzulösen. Kann sein, daß du noch %APPDATA% von Hand auflösen darfst...

[drunken monkey]

@drunken monkey
Würde es nicht reichen wenn die Datei im selben Verzeichnis, indem auch das Programm liegt, abgespeichert bzw. erstellt würde? Man könnte dann ja imo zb so drauf zugreifen:

Code:

private static final File INI_DEST = new File("commands.ini");

...

Das würde wie gesagt nur funktionieren, wenn man das Programm immer aus dem gleichen Verzeichnis aus starten würde. Wenn's allerdings im Path (oder, im Fall von Java, im Classpath) liegt, kann man es auch von jedem anderen Verzeichnis aus starten, und dann würde es in eben diesem verzeichnis nach "commands.ini" suchen - erfolgslos, höchstwahrscheinlich.

Außerdem würde kein vernünftiger nicht-XP-Nutzer auf so eine Idee haben, da du in keinem System abgesehen von XP (und niedriger) Schreibrechte im Anwendungsverzeichnis haben solltest (außer das System ist schlecht konfiguriert oder du hast die Anwendung z.B. auf dem Desktop).

...

Schreibrechte brauche ich auch gar nicht, ich will sie bloß einlesen. Nur der Benutzer muss die Datei ändern können. Daher würde mir das Verzeichnis des Programms eigentlich schon genügen.

Ich weiß nicht, ob Java in der Lage ist, Windows-Variablen aufzulösen. Kann sein, daß du noch %APPDATA% von Hand auflösen darfst...

...

Das schöne Wort "GNAARRRRGGHHRL!" liegt mir auf der Zunge. o_O'
Ich glaube, ich verwende einfach "user.home", das scheint mir noch das Sinnvollste zu sein. <____<''

[DFYX]

Google, erstes Ergebnis:

Sun Developer Network - Retrieving the path where the app is started - Letzter Post

This method will get the path to the jar or class file no-matter where the jar is called from.
// Get the applications path.
File appPath = new File(System.getProperty("java.class.path"));
try
{
appPath = appPath.getCanonicalFile().getParentFile();
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Path: " + appPath.toString());

...

[Jesus_666]

So, das hier wäre eine rudimentäre plattformabhängige Lösung. Immerhin kann man in Java automatisiert bis zum Homeverzeichnis des Users kommen.

Code:

String homedir = System.getProperty("user.home");
String osname = System.getProperty("os.name");
String pathsep = System.getProperty("path.separator");
String configpath;


// Achtung, inkompatibel mit Multiuser-9x.
// user.home evaluiert unter 9x meistens zu ?:\WINDOWS, nur nicht in Muliusersystemen, wo es zu ?:\WINDOWS\PROFILES\<Username> evaluiert.
if ("Windows 95" == osname || "Windows 98" == osname)
  configpath = methodPostedByDFYX().toString() + pathsep + "myapp.ini";
// Keine Ahnung, wie Vista heißt. "Windows Vista" klingt plausibel.
// Achtung, dieser Code muß für jede Locale angepaßt werden, weil Microsoft die Ordnernamen übersetzt!
if ("Windows NT" == osname || "Windows 2000" == osname || "Windows XP" == osname)
  configpath = homedir + pathsep + "Dokumente und Einstellungen" + pathsep + "myapp" + pathsep + "myapp.ini";
elseif ("Mac OS" == osname) // Wir ignorieren Mac OS 9 und früher.
  configpath = homedir + pathsep + "Library" + pathsep + "Preferences" + pathsep + "myapp.ini;"
else // Wir gehen davon aus, daß alle anderen OSe *nix sind
  configpath = homedir + pathsep + ".myapp" + pathsep + "myapp.ini";

Achtung, user.home hat unter Windows einen Bug.

[drunken monkey]

Google, erstes Ergebnis:

Sun Developer Network - Retrieving the path where the app is started - Letzter Post

...

Echt? o_O' Nach was hast du gesucht?
Aber so geht's, zumindest bei mir, nicht, in "java.class.path" ist der gesamte Classpath drinnen, und nicht nur ein Verzeichnis, daher kann man daraus kein File-Objekt erzeugen, zumindest kein sinnvolles.
Allerdings hast du mich auf eine andere Idee gebracht: man könnte "java.class.path" oder (noch besser) "java.library.path" aufteilen und jedes dieser Verzeichnisse nach der INI-Datei durchsuchen. Dann müsste der User nur noch entweder die Datei in ein Verzeichnis im Path verschieben, oder das Verzeichnis mit der Datei zum Path hinzufügen. Klingt für mich sinnvoll.
Oder ist nur unter Windows in "java.library.path" der OS-Path drin?

@ J: Ja, das wäre auch eine akzeptable Lösung, wollte ich schon machen, aber die jetzt mit dem Path gefällt mir eigentlich noch besser. Ich hätte mir vorher schon die System-Properties von Java genauer anschauen sollen. <____<'' Ach, eine Schande, wieviele dieser *jammer, jammer*-Bitte-helft-mir-Threads eigentlich unnötig wären.
Aber bist du dir überhaupt sicher, dass die Zeile bei Win 9x wirklich klappt? Hat bei den beiden OSs "java.class.path" noch eine/n andere/n Bedeutung/Inhalt?

Und weißt du zufällig, ob der Bug in 6.0 schon behoben wurde?

Edit: Meine (hoffentlich) endgültige Lösung:

Code:

String[] pathDirs = System.getProperty("java.library.path").split("\\" + File.pathSeparator + "+");
File f = null;
boolean ini = false;

for (String dir : pathDirs) {
    if (!dir.endsWith(File.separator)) {
        dir += File.separator;
    }
    f = new File(dir + "commands.ini");
    if (f.exists()) {
        break;
    }
}
INI_LOC = f;

[DFYX]

Echt? o_O' Nach was hast du gesucht?

...

Nach Java app path