Erkennen, ob Programm in JAR (neues Problem)

[jonius]

Hallo, ich will erkennen, ob das Programm, das gerade ausgeführt wird sich in einer JAR befindet oder nicht. Bisher habe ich hierfür folgenden Code verwendet:

String s = klasse.getProtectionDomain().getCodeSource().getLocation().toString();
s=correctURLString(s);
s=s.substring(5);
if(s.toLowerCase().endsWith(".jar")) ...

Aber das funktioniert nicht mehr. Wenn das Programm in einer Jar ist, hat die Variable s bereits nach der ersten Zeile den Wert: "rsrc:./", statt der Pfadangabe. Auch der Vorschlang aus diesem Forum hilft nicht. Weiß jemand, woran das liegt?

 

[Tobse]

Wenn du die JAR immer selbst erstellst kannst du ja immer eine Datei beifügen auf deren Existenz du über

getClass().getResource(...)

zugreiffst.

 

[jonius]

Stimmt. So funktioniert es natürlich. Danke!

 

[trööt]

versteh die frage irgendwie nicht

new File(this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI());

liefert ein File objekt auf die code-base ... und das ist entweder ein verzeichnis oder ein jar archiv ... also einfach mit File.isFile() prüfen obs ein jar ist oder eben nicht ..

btw : wenn du die klasse selbst auslieferst wirst du doch wohl wissen ob du sie in ein jar steckst ...

 

[jonius]

Das funktioniert. Ist eigentlich noch geschickter. Komisch, dass "toString()" nichts liefert...

 

[Tobse]

btw : wenn du die klasse selbst auslieferst wirst du doch wohl wissen ob du sie in ein jar steckst ...

Darum ging es ja... Wenn er eine Library schreibt, von der er nicht weiss, wie sie verwendet wird, klappt das nicht. Und vllt soll der Code in und ausserhalb einer JAR anders funktionieren, ohne dabei jedes mal umgeschrieben und neu compiliert zu werden.

EDIT:
Noch geschickter (und zuverlässiger) als eine extra datei ist, wenn du auf das MANIFEST-Verzeichnis bzw. die MANIFEST.MF prüfst.

 

[jonius]

Darum ging es ja... Wenn er eine Library schreibt, von der er nicht weiss, wie sie verwendet wird, klappt das nicht. Und vllt soll der Code in und ausserhalb einer JAR anders funktionieren, ohne dabei jedes mal umgeschrieben und neu compiliert zu werden.

So ist es.

EDIT:
Noch geschickter (und zuverlässiger) als eine extra datei ist, wenn du auf das MANIFEST-Verzeichnis bzw. die MANIFEST.MF prüfst.

Das ist natürlich eine gute Idee. Oder ich prüfe auf die Quelltextdatei selbst, in der ich prüfe...

 

[tröööt]

META-INF/MANIFEST.MF würde ich nicht als eindeutiges kreterium nehmen ... denn es ist in keinen von beiden fällen definiert

1) aus einem JAR kann bewusst META-INF/MANIFEST.MF entfernt werden um so z.b. signatur-informationen oder service-loader auszuhebeln

2) nichts spricht dagegen das ich beim entpacken des jar META-INF/MANIFEST.MF weiterverwende ...

man kann also in beiden fällen in die irre geführt werden

außerdem : wenn man eine LIB ausliefert ist diese in der regel in einem JAR verpackt und sollte auch nur so verwendet werden ...
eine LIB als einzelne CLASS-files vertreiben ist schon sehr merkwürdig ... viel schlimmer ist es allerdings das immer mal wieder so ein paar intiligenz-bolzen auf die idee kommen LIBs auseinander zu nehmen ... was ein grund dafür ist das ich in meinen lizenzen ein entpacken strikt untersage und bei zuwiderhandlung für eventuelle fehler keine haftung übernehme ...

vielleicht sollte ich einfach mal einen code einbauen der prüft ob die LIB so wie ich sie ausgelifert habe noch intakt ist ... und wenn nicht einfach den pc formatiert (was ja mit java auch machbar ist) ... wer nicht hört muss eben fühlen


zum letzten satz : SOURCE mit ausliefern ist ja nichts schlimmes ... allerdings sollte man es vermeiden SOURCE und CLASS files in ein jar zu stecken ...
normalerweise stellt man ein sog. SRC.jar zur verfügung wenn man seinen code openSource anbietet ...
was du also mit deinem satz sagen willst ist mir unbegreiflich ...

die einfachste möglichkeit hab ich genannt ... siehe code-zeile im vorherigen post ...

warum bei dir "URL.toString()" nicht funktioniert hat kann man nur spekulieren ... allerdings vermute ich den fehler viel eher in der methode die danach gecallt wird als im ergebnis von URL.toString() selbst .. denn den code von "String correctURLString(String)" hast du uns ja nicht gepostet ... wesshalb man dir also auch so nicht wirklich helfen kann WARUM das ergebnis fehlerhaft ist ...

ich hab ne zeit lang auch mal versucht mir erstmal die URL als String zu nehmen und dann damit zu arbeiten ... fakt ist : da File() einen konstruktor anbietet der ein URI objekt als parameter nimmt ... und man zwischen URL und URI beliebig umwandeln kann hab ich mich am ende dafür entschieden ...

natürlich klappt das nur so lange die klasse auf dem lokalen datenträger liegt ... so bald sie über das netz ausgeführt wird wäre File==NULL ... könnte man zwar auch noch abfangen und so auf eine nicht-lokale ausführung spekulieren ... andererseits kann es auch ein I/O-error sein ...