# Aktueller Pfad des Programms (.jar) ermitteln



## Aruhn (11. Mai 2010)

Mein fertiges JAVA-Programm hab ich nun mit eine ausführbare .jar Datei gepackt.
Dieses Programm soll nun wahllos unter jedem System unter einen beliebigen Pfad eingesetzt werden können, was soweit auch kein Problem darstellt. 

Das Programm baut aber auf eine externe Textdatei auf wo Konfigurationen gespeichert werden die zum Nutzen (z.B. für die Anmeldung) zwingend benötigt wird. Nun muss ich den Pfad des Verzeichnises ermitteln wo sich die .jar befindet. 

Der Aufbau ist so, die ausführbare Datei befindet sich in einem Verzeichnis (ich nenn es mal "Anwendung") und die Textdatei befindet sich in einem anderem Verzeichnis ("Doc") und die beiden Verzeichnisse befinden sich in dem Verzeichnis (Programm), welches sich widerrum sonst wo im Betriebssystem (Windows und Linux) befindet.

Der Aufhänger ist nun folgender, ich weiß nicht so richtig wie ich nun das Verzeichnis, wo sich die .jar Datei befindet ermitteln kann. :bahnhof:

Folgendes hab ich ausprobiert:

```
File fi = new File("");
		String verz = fi.getAbsolutePath();
```

Funktioniert in der Entwicklungsumgebung wunderbar, aus der JAR-Datei heraus wird man nur das Standard Benutzerverzeichnis (in meinem Falle /home/user) angezeigt - es befindet aber in Wahrheit ein paar Verzeichnisse weiter. Korrekterweise müsste es also "/home/user/workspace/Anwendung/Programm" lauten.

Zweite Variante
[JaVA]String benutzerverz = System.getProperty("user.dir");[/code]

Das selbe wie oben.

Dritte Variante

```
URL url = Anmeldung.class.getResource("Anmeldung.java");
```
In der Entwicklungsumgebung wird der vollständige Pfad angezeigt - mit voranstehender file: Klausel.
Im entwickelten Programm wird mir dagegen "onejarrogMain:Anmeldung.java" präsentiert. 

Wie kann ich nun den Pfad des Verzeichnisses ermitteln wo sich die ausführbare Datei befindet? 

Über jede Hilfe und Anregung wäre ich sehr dankbar.


----------



## Michael... (11. Mai 2010)

Bei meinen Anwendungen liegen solche Dateien im selben Verzeichnis wie die jar-Files oder in einem Unterverzeichnis.
Für Windowssysteme lege ich im gleichen Verzeichnis ein bat-File an, das den ClassPath auf die jars und das aktuelle Verzeichnis legt und somit kann man egal wo man dieses Verzeichnis hinkopiert immer per getResource(...) auf benötigte Dateien zugreifen.


----------



## Aruhn (11. Mai 2010)

Ich hab gerade festgestellt, dass das jediglich ein Problem unter meinem Linux (Ubuntu) ist.
Unter Windows funktioniert dies mit der zweiten Variante. Sogar wenn sich das Programm auf einem USB-Stick befindet, der Pfad wird korrekt bestimmt. 

Das überrumpelt mich jetzt gewaltig. :bahnhof:
Warum tanzt die Anwendung bei Ubuntu so gewaltig aus der Reihe?

Das Problem ist, weshalb ich den Ordner Docs auch brauche, das im Programm z.B. PDF-Dokumente erzeugt werden die eben in diesem Ordner abgelegt werden (er ist momentan statisch und wird deshalb gebraucht).


----------



## Java-Freak (11. Mai 2010)

ich hab auch mal was ähnliches geschrieben wo zwar keine Einstellungen odda so gespeichert weden sondern iwelche codes in ne xml aber das prinzip dürfte das gleiche sein:
du musst nicht den absoluten pfad ermitteln sondern nur ../Programm/Doc/DateiName.txt oder ./Doc/DateiName.txt schreiben
so gings zumindest bei meim fedora


----------



## Aruhn (11. Mai 2010)

So ähnlich war ich auch schon im Vorfeld herangegangen.

```
String benutzerverz = System.getProperty("user.dir");
String txtPfad = benutzerverz + "/../Docs/server.txt";
```

War mein Gedanke aber der funktioniert so nur unter Windows (natürlich dann mit Backslash statt Slash). 
Unter Linux spuckt mir System.gerProperty("user.dir") nur /home/user aus - folglich sagt mir die Stringvariable txtPfad "/home/user/../Docs/server.txt" - und sucht das ganze also nur unter /home. 

Das Programm könnte sich ja auch unter /home/user/xy/xy/xy befinden - da bringt mir das Ganze gleich viel weniger. Ich brauch auf jedenfall irgendwie das aktuelle Programmverzeichnis. 

Ich kann ja nicht einmal eine "Geistdatei" mit new File("/../none.txt") ein Verzeichnis weiter Vorn erstellen und die Geistdatei zur Pfadermittlung des Programms missbrauchen, in diesem Falle wird wieder von /home/user ausgegengen - es wird also Versucht die none.txt Datei unter /home zu erstellen und das scheitert dann an keinen Schreibrechten und new File("none.txt") wird unter /home/user erstellt. 

Derzeit arbeite vorrübergehend damit das sich der Ordner "Docs" eben im Userverzeichnis befindet.


----------



## mabuhay (11. Mai 2010)

Hallo

Ich hatte erst gerade die Gleiche Frage: http://www.java-forum.org/allgemeine-java-themen/99655-speichern-einstellungen.html




Aruhn hat gesagt.:


> Ich hab gerade festgestellt, dass das jediglich ein Problem unter meinem Linux (Ubuntu) ist.
> Unter Windows funktioniert dies mit der zweiten Variante. Sogar wenn sich das Programm auf einem USB-Stick befindet, der Pfad wird korrekt bestimmt.
> 
> Das überrumpelt mich jetzt gewaltig. :bahnhof:
> Warum tanzt die Anwendung bei Ubuntu so gewaltig aus der Reihe?



Das "Problem" ist, dass jeweils der Arbeitspfad von Java verwendet wird. Führst du es in der Konsole aus, z.B. in /home/user mit java -jar /pfad/zur/jar ist der Arbeitspfad /home/user, führst du das gleiche in /home/user/verzeichnis aus ist der Arbeitspfad /home/user/verzeichnis. Bei Ubuntu ist der Arbeitspfad halt immer das Benutzerverzeichnis, wo eigentlich auch alle Konfigurationsdateien liegen.

Ich habs  so gelöst:

```
//Windows
settingsPath = System.getenv("APPDATA");
//Unix
if (settingsPath == null) {
	settingsPath = System.getProperty("user.home");
}
```
und die Datei dann als .Programmname.settings abgelegt (zu beachten der Punkt am Anfang). Somit wird die Konfigurationsdatei in Windows unter den Programmeinstellungen und unter Unix im home-Verzeichnis (Versteckt) abgelegt. Wie sich das ganze bei Mac verhält weiss ich noch nicht.

Für den Ordner Docs kannst du ja den Benutzer wählen lassen, wo der angelegt werden/sein soll.

mfg


----------



## Michael... (12. Mai 2010)

Ich würde mal behaupten meine Variante funktioniert Plattformunabhängig, nur dass man auf entsprechenden Systemen anstelle des batch Skripts ein shell Skript verwenden muss, bzw. anderweitig sicherstellen muss, dass benötigte Verzeichnisse im ClassPath sind.


----------



## hemeroc (12. Mai 2010)

Da ich das Problem auch in meiner Anwendung hatte hier meine Lösung:


```
new File(DEINEKLASSE.class.getProtectionDomain().getCodeSource().getLocation().toURI().getPath());
```

LG Hemeroc


----------



## FArt (12. Mai 2010)

Konfigurationen sollte man am besten mit ins JAR packen (wenn sie nicht verändert werden oder spezfisch für jeden Benutzer benötigt werden). Dann werden sie über den Klassenpfad geladen.
Sonst kann man die Ressourcen relativ zum Ausführungsverzeichnis ablegen. Bei einem executable JAR dann den Klassenpfad in der Manifestdatei pflegen.
Laufzeitkonfigurationen (besonder benutzerspezifische) sollten im Benutzerverzeichnis abgelegt werden, welches leicht ermittelt werden kann.

Über Umwege die Pfade irgendwie herauszubekommen funktioniert nicht plattformunabhängig. Skripten sind natürlich auch eine Möglichkeit, aber die muss man auch plattformabhängig pflegen.


----------



## mabuhay (12. Mai 2010)

hemeroc hat gesagt.:


> Da ich das Problem auch in meiner Anwendung hatte hier meine Lösung:
> 
> 
> ```
> ...



Soviel ich weiss funktioniert das auch nicht. Starte dein Jar mal aus der Konsole. z.B. gehe in irgend einen Ordner und starte dann java -jar /Pfad/zum/jar und scha dir die Ausgabe des Pfades an. Je nachdem wo du bist wirst du sehr wahrscheinlich einen anderen Pfad bekommen. Ausser du nimmst an dass dein java-programm nur unter Windows ausgeführt wird und nur durch doppelklick auf die jar.


----------



## Java-Freak (12. Mai 2010)

also bei mir gings... lass des / vor den punkten mal weg
noch ne frage, wenn du ne jar startest, wir machst du des dann?
weil, bei mir war des mal so, des der dateimanager dolphin von wo ichs gestartet habe sowas immer in /home/user/Documents/ abgelegt hat. das lag dan aber nicht an meim programm sondern war von dem dateimanager bedingt. versuchs mal das jar mit 'java -jar DateiName.jar' aus der konsole zu starten und schau dann obs geht


----------

