Datei relativ zur Lage des jar-files lesen

[Andi_CH]

Ich hab zwar X Hinweise gefunden wie man eine Datei liest, die in einem jar-file ist, aber in meinem Fall handelt es sich um eine Konfigurationsdatei, die auch geschrieben werden muss und die am selben Ort wie die Installation liegen muss, absolute Pfadangaben sind also nicht möglich.

Sicher schon 1000 mal gelöst, wer verrät mir die Suchbegriffe nach denen ich schon eine ganze Weile suche?

 

[maki]

Pfad zur Jar:
[c]getClass().getProtectionDomain().getCodeSource().getLocation().getPath();[/c]

 

[Stream1241]

Hallo,

hatte ja jetzt quasi das selbe Problem!!
Und zwar musst du über relative Pfadangaben in bezug zum Ort deiner .jar datei arbeiten.
So hab ich es z.B gelöst :

    public static void verzeichnisErstellen() throws IOException {
        String path = "./Lektionen/";
        String fileName = "sprachen.txt";
        String dirName = sammlungsname;
        File file = new File(path + dirName + "/" + fileName);
        File dir = new File(path + dirName);

Und zwar wird jetzt in dem Ordner oder Ort wo die .jar datei liegt ein Lektionen Verzeichniss erwartet, genausogut kannst du auch mit getClass().getResource("KartenLabel.png") auf Dateien innerhalb deiner Jar zugreifen (Sehe gerade das du das schon wusstest!;-))

Hoffe habe deine Frage nicht falsch verstanden und konnte dir helfen!
gruß

 

[Andi_CH]

Danke euch beiden, ich werde das gleich ausprobieren, wobei ich noch nicht so recht glaube, dass das zweite ohne das erste funktioniert ;-)

Zur Erklärung:
Per Installation werden die jars und die Konfigdatei (bis anhin war die ja in einem der Rachive drin, aber seit Neuestem muss der Benutzer auch Einstellungen verändern können) in einen "beliebigen" Pfad kopiert.

<Installationspfad>/bin/*.jar
<Installationspfad>/config/*.xml

 

[nrg]

ich mach das immer so wie hier beschrieben:

Smartly load your properties - JavaWorld

Der Ansatz entspricht aber dem von maki

 

[maki]

Der Ansatz entspricht aber dem von maki

Tut er nicht

Der Link von dir ist mein Lieblingslink wenn es darum geht, Ressourcen aus einer jar bzw. dem Classpath zu laden, aber Andi_CH will ja etwas anderes

 

[nrg]

warum? ergänzt man den Class-Path um den relativen Pfad (./conf o.ä), kann man die Konfigurationsdateien doch über den ClassLoader laden.

 

[irgendjemand]

Pfad zur Jar:
[c]getClass().getProtectionDomain().getCodeSource().getLocation().getPath();[/c]

hmm ... liefert am ende auch nur ne URL ... würde also wenn überhaupt noch toURI() einbauen ...

aber alles in allem dürfte [c]new File(".");[/c] immer noch das einfachste sein ...

*alternativ in J7 mit NIO.2 arbeiten

 

[maki]

hmm ... liefert am ende auch nur ne URL ... würde also wenn überhaupt noch toURI() einbauen ...

Ja, und URL/URI ist ja das was man will, den Pfad halt

aber alles in allem dürfte [c]new File(".");[/c] immer noch das einfachste sein ...

Darauf trifft man immer wieder, aber die wenigstens wissen was new File(".") wirklich macht, damit bekommt man (über umwege) den Pfad zum Workingdirectory, nicht zur Jar.
Das Workingdirectory kann im Prinzip jedesmal woanders sein (kommt darauf an wie die Java App gestartet wurde) und hat ursächlich rein gar nix mit der Location der Jar zu tun.. nur wenn die Jar im selben Verzeichnis gestartet wurde in der sie liegt stimmt dann das Ergebnis.

 

[irgendjemand]

Ja, und URL/URI ist ja das was man will, den Pfad halt

naja ... nur ist URI deutlich nützlicher als URL ... wenn man vorhat es in einem File objekt zu verwenden ... denn die URL müsste man erstmal decode *gerade unter XP wo aus "Documents and Settings" mal eben "Documents%20and%20Settings wird ... und wenn man das File übergibt ... kommt eine FileNotFoundException*

Darauf trifft man immer wieder, aber die wenigstens wissen was new File(".") wirklich macht, damit bekommt man (über umwege) den Pfad zum Workingdirectory, nicht zur Jar.
Das Workingdirectory kann im Prinzip jedesmal woanders sein (kommt darauf an wie die Java App gestartet wurde) und hat ursächlich rein gar nix mit der Location der Jar zu tun.. nur wenn die Jar im selben Verzeichnis gestartet wurde in der sie liegt stimmt dann das Ergebnis.

ist mir durch aus bewusst ... aber in der regel trifft dies zu wenn man eine JAR per "doppelklick" öffnet ...
wenn über terminal dann entspricht [c]new File(".");[/c] genau dem pfad in dem man sich im terminal gerade befindet

 

[maki]

naja ... nur ist URI deutlich nützlicher als URL ... wenn man vorhat es in einem File objekt zu verwenden ... denn die URL müsste man erstmal decode *gerade unter XP wo aus "Documents and Settings" mal eben "Documents%20and%20Settings wird ... und wenn man das File übergibt ... kommt eine FileNotFoundException*

Eine URL kann man direkt in eine URI wandeln und umgekehrt, dafür gibt es spezielle Methoden.

ist mir durch aus bewusst ... aber in der regel trifft dies zu wenn man eine JAR per "doppelklick" öffnet ...
wenn über terminal dann entspricht new File("."); genau dem pfad in dem man sich im terminal gerade befindet

"In der regel" sollte man das sagen was man meint, wenn man das Workingdiretory will, ist file(".") ein möglicher Weg, wenn man aber die Location der Jar will, ist new File(".") ein weg der mal funktionieren kann und mal nicht, eben nur ein Q&D Hack der meistens, aber nicht immer funktioniert, sollte auch mal gesagt werden.
Man sollte nicht nur Blind aus Google C&P'en, ist nicht alles Gold was da so rumliegt

 

[irgendjemand]

das es URL.toURI() und URI.toURL() gibt weis ich ... sonst hätte ich es ja oben nicht erwähnt ...

mein haupt-post-grund war eigentlich das problem was man bekommt wenn man OS-filesystem-URLs / URIs einem File objekt übergeben will ... das geht unter Windows meist grundsätzlich schief da entweder immer ein leerzeichen drin ist was erstmal decoded werden muss ... oder sonderzeichen in Win-1251 was java auf biegen und brechen nicht versteht *und windows selbst unter NT6.1 von haus aus immer noch nicht mit UTF-8 arbeitet wie es unix schon seit geburt vormacht*

ob man sich also nun mit Win-1251 rumschlägt und versucht die URL/URI zu decoden ... oder ob man sich selbst über File-objekte zum jar navigiert ... hmm ... alles sehr schwierig und frag würdig ...

unter unix geht das ganze sehr viel einfacher : einfach URLDecoder.decode(URL, "UTF-8") und man hat ein verwendbaren pfad für ein File-objekt ...

das problem liegt also hier weniger an java selbst seinen eigenen pfad zu finden ... als viel mehr an windows und M$ die sich von beginn an bis heute erfolgreich gegen alle standards verweigern

 

[Andi_CH]

Das was Maki gepostet hat, macht wenigstens in der Entwicklungsumgebung das was ich will. Das andere wird sich noch zeigen, aber ich sehe da keine grösseren Probleme.

Die Aufgabenstellung ist doch ganz einfach ;-) Ich muss auf eine Datei zugreifen können, die relativ zum jar (z.B. in ../config) liegt und so nebenei ist es gut, wenn derselbe Code auch auf Linux und consorten läuft (aber das wird er ja auch)

 

[irgendjemand]

wie gesagt : unter unix/mac wirst du damit die wenigstens probleme bekommen weil diese systeme alle UTF-8 verwenden

das einzige was tricky wird ist halt winschrott ...

 

[maki]

@irgendjemand
Ist natürlich richtig dass die Pfad Konvertierung unter Windows oft zu einem Glücksspiel bzw. Katastrophe wird und es ein Vorteil ist wenn man von Anfang an ein File Objekt hat anstatt erst Pfade konvertieren zu müssen.

 

[Crian]

Konfigurationsdaten würde ich immer in einem eigenen Verzeichnis unter

user.home

anlegen.

String home = System.getProperty("user.home", ".");
File localPath = new File(home + "/.LocalSpecialDirctory");

 

[irgendjemand]

und genau das war ja mein ursprünglicher anreiz drauf hinzuweisen das gerade unter win eine verwendung von URL/URI eher sub-optimal ist ... *wobei dieses ProtectedDomain.getCodeBase() unter unix sicher eine der besten lösungen ist*

ich selbst habe immer damit zu kämpfen wenn es um "sonderzeichen" in Win-1251 geht ... denn da fliegt fast immer eine exception ...

%20 - %7F kann man ja dank ASCII noch selbst parsen ... aber selbst von %80-%FF wirds ja schon schwierig ... ob man nun ANSI , Win-1251 oder UTF-8 nimmt hat ja selbst da schon seine auswirkungen ...

*wobei das größte problem eigentlich die user sind welche sonderzeichen in datei- und ordner-namen verwenden ... und diese "helden" bei M$ welche sich dachten in eine filesystem-struktur leerzeichen einzubauen ...

warum eigentlich nicht mit Preferences die Win-registry zumüllen ? machen doch alle anderen auch ... xD

[edit]

Konfigurationsdaten würde ich immer in einem eigenen Verzeichnis unter

user.home

anlegen.

String home = System.getProperty("user.home", ".");
File localPath = new File(home + "/.LocalSpecialDirctory");

ist natürlich das vernünftigste wie man es von unix kennt[/edit]