new Reader(dateiname) und getResourceAsStream

[nrg]

Hallo Zusammen,

Ich habe hier ein Projekt, welches oft auf das Installationsverzeichnis zugreift (z.b. für Licensecheck, Properties-load etc.)

Meine Properties lade ich mit ClassLoader:

	Properties properties = new Properties();
	ClassLoader loader = ClassLoader.getSystemClassLoader();
	properties.load(loader.getResourceAsStream(filename));

Mein Licensecheck und viele andere Dinge mach ich einfach mit einer relativen Pfadangabe:

	BufferedReader bfr = new BufferedReader(new FileReader("meinelic.lic"));
	// oder zb
	BufferedReader bfr = new BufferedReader(new FileReader("lic" + java.io.File.separator + "meinelic.lic"));

Ich habe aber mit der zweiten Option irgendwie immer Bauchschmerzen, weil ich irgendwann irgendwo mal gelesen habe, dass man sowas aus irgendwelchen Gründen nicht machen soll.

Lange Rede kurzer Sinn: sind meine Bauchschmerzen berechtigt oder habe ich da einfach was falsch aufgeschnappt? Kann mir vorstellen, dass man die Properties halt mit ClassLoader läd, weil dort ein Stream benötigt wird und "String-Pfäde" kann man ohne bedenken relativ angeben.

Danke schonmal

Grüße

nrg

 

[eRaaaa]

Hast du mal versucht das Ganze zu einer jar-Datei zusammen zu schustern und dann (erfolgreich/fehlerfrei) ausgeführt?

 

[nrg]

ja das lief soweit alles gut. JAR-Datei mit angepasster Manifest, worin der CP auf das aktuelle Verzeichnis (blabal .) erweitert wird.

Vielleicht habe ich auch ganz einfach da irgendwo was falsches aufgeschnappt .

 

[nrg]

also ist jetzt meine Vorgehensweiße die übliche Praxis oder würdet ihr das anders machen? Mehr möchte ich eigentlich garnicht wissen

 

[Wildcard]

also ist jetzt meine Vorgehensweiße die übliche Praxis oder würdet ihr das anders machen? Mehr möchte ich eigentlich garnicht wissen

Deine Bauchschmerzen sind berechtigt, du kannst dich nicht darauf verlassen, dass das Ausführungsverzeichnis dem Root Verzeichnis deines Programms entspricht.
Eine häufiges Vorgehen ist das eigene Programm nicht über die Jar, sondern einen Launcher zu starten und der Launcher setzt das Ausführungsverzeichnis für die Applikation.
So ein Launcher kann zB ein Shellscript oder ein binary sein.

 

[nrg]

ah ok, also doch. erst mal Danke für die Erklärung. Und was sind jetzt die Alternativen? Wie ist hierbei die "Best Practice"?
Ich nehme an der ClassLoader bei den Properties ist ok. Wie lade ich nun Grafiken und Dateien relativ zum ausführenden Verzeichnis?

 

[Wildcard]

Wie gesagt, üblicherweise in dem man einen Launcher vorschaltet der die jar startet. Mit einem Hack kann man zwar theoretisch den Pfad eines jars herausfinden, aber das ist wirklich nur ein Hack.

 

[Empire Phoenix]

Oder nen installer, der packt dann zb in den X ordner den installationpath, wo dann die ressourcen liegen. (Die jar kann dann auch dahinkopiert werden oder zb per webstart)
Und speichert sich das irgetwo wo er es wiederfindet zb in den user path
Dannach kann man die dann über FileReader problemlos lesen.

	private File getInstallPath() {
		String installpath = "";

		String path = System.getProperty("user.home");
		System.out.println(path);
		boolean create = false;
		try {
			File installationrecord = new File(path
					+ "/newhorizons.installrecord");
			Scanner installrecordscanner = new Scanner(installationrecord);
			if (installrecordscanner.hasNextLine()) {
				installpath = installrecordscanner.nextLine();
			} else {
				installrecordscanner.close();
				throw new Exception("Cant read local path");
			}
			installrecordscanner.close();
		} catch (Exception e) {
			e.printStackTrace();
			System.out.println("No installation record found");
			create = true;
		}

		if (create) {
			installpath = GetInstallFolder();
			new File(installpath).mkdir();

			try {
				FileWriter installationrecord = new FileWriter(path
						+ "/newhorizons.installrecord");
				BufferedWriter out = new BufferedWriter(installationrecord);
				out.write(installpath + "\n");
				out.write("This file is important for NewHorizons to run!, do not change or remove it");
				out.flush();
				installationrecord.flush();
				out.close();
				installationrecord.close();
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
		System.out.println(installpath);
		File returnvalue = new File(installpath);
		returnvalue.mkdirs();
		System.out.println(returnvalue);
		return returnvalue;
	}

	private static String GetInstallFolder() {
		JFileChooser chooser = new JFileChooser();
		chooser.setDialogTitle("Bitte Installationsordner auswählen");
		chooser.setDoubleBuffered(true);
		chooser.setMultiSelectionEnabled(false);
		chooser.setDialogType(JFileChooser.OPEN_DIALOG);
		chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);

		int returnVal = chooser.showOpenDialog(new JFrame());
		if (returnVal == JFileChooser.CANCEL_OPTION) {
			System.exit(0);
		} else if (returnVal == JFileChooser.APPROVE_OPTION) {
			String result = chooser.getSelectedFile().getAbsolutePath();
			return result;
		}
		return "";
	}

 

[turing]

Macht dies nicht System.getProperty("user.dir")?

Wie gesagt, üblicherweise in dem man einen Launcher vorschaltet der die jar startet. Mit einem Hack kann man zwar theoretisch den Pfad eines jars herausfinden, aber das ist wirklich nur ein Hack.

 

[Gastredner]

Macht dies nicht System.getProperty("user.dir")?

Nein, user.dir gibt dir das Arbeitsverzeichnis zurück, nicht den Ort deines Programms (wobei dies zumeist das gleiche Verzeichnis ist, nicht jedoch notwendigerweise).

 

[turing]

Dann würde mir noch

getClass().getProtectionDomain().getCodeSource().getLocation()

einfallen. Das Problem dürfte hierbei sei, dass man sich sicher sein muss, dass der Security Manager sein OK gibt. Habe keinerlei praktsiche Erfahrungen damit.

 

[Wildcard]

Dann würde mir noch

getClass().getProtectionDomain().getCodeSource().getLocation()

einfallen. Das Problem dürfte hierbei sei, dass man sich sicher sein muss, dass der Security Manager sein OK gibt. Habe keinerlei praktsiche Erfahrungen damit.

Das ist besagter Hack den ich eingangs erwähnte. Den String muss man anschließend noch parsen um auf Pfad zu kommen. Würde ich nach Möglichkeit vermeiden.

 

[Empire Phoenix]

Nein, user.dir gibt dir das Arbeitsverzeichnis zurück, nicht den Ort deines Programms (wobei dies zumeist das gleiche Verzeichnis ist, nicht jedoch notwendigerweise).

Nene, das liefert dir dein User verzeichnis wieder.

Also unter win7 zb

C:\Users\username\

unter xp

c:\dokumente und einstellungen\ect..

denke unter linux wird dir das dann das vergelichbare verziechnis geben. Sinn der aktion ist, das das immer ein Vorhandener pfad ist. (Zb muss es nicht c:\ sein unter windows, das könnte auch nen cardreader sein wenn man den bei der installation nicht abgezogen hatte)

 

[turing]

Du meinst user.home nicht user.dir

 

[Empire Phoenix]

Main ich ja, ist auch im Code drinnen, du hast mir das user.dir untergeschoben ^^ Und ich habs nichtmal bemerkt und einfach gemütlich weiterzitiert.

 

[nrg]

ok, die gesuchte Methode getExecutiveDir() o.ä. gibt es wohl nicht. Der besagte "Hack" kann wohl auch nicht die "Best-Practise" sein.
D.h. es würde schon reichen, wenn ich die JAR mit einer BAT ausführe, die mein cd auf das InstallDir setzt bzw. vom InstallDir aufgerufen wird (cp wird ja über die Manifest gesteuert). Hab ich das richtig verstanden?
Wenn ja, danke für die Hilfe

 

[Wildcard]

D.h. es würde schon reichen, wenn ich die JAR mit einer BAT ausführe, die mein cd auf das InstallDir setzt bzw. vom InstallDir aufgerufen wird (cp wird ja über die Manifest gesteuert). Hab ich das richtig verstanden?

Ja, das würde funktionieren.

 

[nrg]

Ja. So mache ich es derzeit auch. Aber es wäre natürlich wünschenswert, wenn das Programm bei folgendem Aufruf, nicht auf die Nase fallen würde:

[c]
C:\>java -jar C:\Programme\MeinProg\MeinProg.jar
[/c]

naja gut. Danke nochmal allen Beteiligten für die Tipps