Java System.getProperty ("user.dir") unter Mac OS X

Question

Ich habe ein Anwendungspaket auf Mac OS X 10.4 auf dem Desktop. Meine Anwendung sucht nach einem Ordner mit dem Namen "resources", in dem die anzuzeigenden Dateien aufbewahrt werden (an demselben Speicherort wie das ausführbare JAR). Ich weiß, dass es auch einen Ordner namens "Ressourcen" im App-Bundle gibt, tut mir leid, wenn das verwirrend ist, aber ich habe nie auf einem Mac programmiert und wusste nicht, dass das derselbe Name wäre.

In Windows, wenn ich System.getProperty("user.dir") aufrufen ich bekomme den Ort, an dem die ausführbare JAR-Datei befindet. Genau das, was ich wollte.

Warum dann, wenn ich ein Anwendungspaket ausführen, ist die getProperty "/" zurück? Das ist alles. Ich habe erwartet, dass es etwas wie "/Users/user_name/Desktop" ... zurückgibt, wo sich mein App-Bundle befindet.

Answer 1

Das liegt daran, dass "user.dir" das aktuelle Benutzerverzeichnis angibt, das beim Ausführen der JVM aktiv ist. In Windows ist dies oft der Speicherort des JAR, sofern Sie nichts anderes angeben. In OSX gibt es vielleicht kein Konzept für ein aktuelles Verzeichnis, aber es hat wahrscheinlich einen anderen Standard.

Obwohl ich ausdrücklich nie diesen Code unter OSX getestet, können Sie dies versuchen, das Verzeichnis zu suchen, von denen jede Klasse geladen wurde:

static public File getClassLocation(Class cls, boolean trmjar) { 
    ClassLoader       clsldr;              // class loader 
    URL         urlobj;              // url object 
    String        exturl;              // external form of URL 
    String        lwrurl;              // lowercase external form of URL 
    File        rtnfil;              // return file 

    if((clsldr=cls.getClassLoader())==null) { clsldr=ClassLoader.getSystemClassLoader(); } 

    if((urlobj=clsldr.getResource(cls.getName().replace('.','/')+".class"))==null) { 
     return null; 
     } 

    exturl=urlobj.toExternalForm(); 
    lwrurl=exturl.toLowerCase(); 
    while(lwrurl.startsWith("jar:") || lwrurl.startsWith("file:/")) { 
     if(lwrurl.startsWith("jar:")) { 
      if(lwrurl.indexOf("!/")!=-1) { exturl=exturl.substring(4,(exturl.indexOf("!/"))); }  // strip encapsulating "jar:" and "!/..." from JAR url 
      else       { exturl=exturl.substring(4      ); }  // strip encapsulating "jar:" 
      } 
     if(lwrurl.startsWith("file:/")) { 
      exturl=exturl.substring(6);                // strip encapsulating "file:/" 
      if(!exturl.startsWith("/")) { exturl=("/"+exturl); } 
      while(exturl.length()>1 && exturl.charAt(1)=='/') { exturl=exturl.substring(1); } 
      } 
     lwrurl=exturl.toLowerCase(); 
     } 
    exturl=java.net.URLDecoder.decode(exturl,"UTF-8"); 
    rtnfil=new File(exturl); 
    if(lwrurl.endsWith(".class") || (trmjar && lwrurl.endsWith(".jar"))) { rtnfil=rtnfil.getParentFile(); } 
    if(rtnfil.exists()) { rtnfil=rtnfil.getAbsoluteFile(); } 
    return rtnfil; 
    } 

es für mich jahrelang zuverlässig unter Windows gearbeitet hat, für alle Versionen von Java seit Java 1.

Answer 2

Ich habe stattdessen die Systemeigenschaft "user.home" anstelle von "user.dir" verwendet. Auf diese Weise muss ich mir keine Gedanken darüber machen, wo die JVM sucht. Ich habe das Anwendungsbundle referenziert meine JAR-Datei direkt mit einem Bash-Skript als ausführbar durch die Datei info.plist aufgerufen. Ich kann immer die Dateien, die von der App angezeigt werden, auf die Benutzer zu Hause legen, da dieser Ort immer einen Pfad zurückgibt.