CODEWITHSUNDEEP
javamacospropertiessystem
Ken
Ken

Reputation:

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

I have an application bundle on Mac OS X 10.4 on the desktop. My application looks for a folder named "resources" in which files to be displayed are kept (kept in the same location as the runnable JAR). I know there is a folder named "Resources" within the app bundle too, sorry if thats confusing, but I never programmed on a Mac and didnt know this would be the same name.

In Windows, when I call System.getProperty("user.dir") I get the location at which the runnable JAR file is located. Exactly what I wanted.

Why then when I run an application bundle is the getProperty returning "/"? Thats all. I expected it to return something like "/Users/user_name/Desktop"...which is where my app bundle is located.

Upvotes: 1

Views: 15633

Answers (2)

L. Cornelius Dol
L. Cornelius Dol

Reputation: 64026

That's because "user.dir" indicates the current user directory in effect when the JVM is run; in Windows, this is often the location of the JAR unless you specify otherwise. In OSX there may well be no concept of a current dir, but more likely it just has a different default.

Though I have never specifically tested this code under OSX, you can try this to locate the directory from which any class was loaded:

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;
    }

it's worked reliably for me for years under Windows for all versions of Java since Java 1.

Upvotes: 1

Ken
Ken

Reputation:

I instead used the system property "user.home" instead of "user.dir". This way i do not have to worry about where the JVM is looking. I have the application bundle refernce my jar file directly using a bash script as the executeable called by the info.plist file. i can always place the files to be displayed by the app on the users home because that location will always return a path.

Upvotes: 2

Related Questions