0

デスクトップの Mac OS X 10.4 にアプリケーション バンドルがあります。私のアプリケーションは、表示されるファイルが保持される「resources」という名前のフォルダーを探します (実行可能な JAR と同じ場所に保持されます)。アプリバンドル内にも「Resources」という名前のフォルダーがあることは知っていますが、混乱している場合は申し訳ありませんが、Macでプログラミングしたことはなく、これが同じ名前になることも知りませんでした.

Windows では、呼び出すSystem.getProperty("user.dir")と、実行可能な JAR ファイルがある場所を取得します。まさに私が欲しかったもの。

では、アプリケーション バンドルを実行すると、getProperty が「/」を返すのはなぜですか? それで全部です。「/Users/user_name/Desktop」のようなものが返されることを期待していました...これは、アプリバンドルが配置されている場所です。

4

2 に答える 2

1

代わりに、「user.dir」の代わりにシステムプロパティ「user.home」を使用しました。このようにして、JVMがどこを探しているかを心配する必要はありません。info.plistファイルによって呼び出される実行可能ファイルとしてbashスクリプトを直接使用して、アプリケーションバンドルにjarファイルを直接参照させます。その場所は常にパスを返すため、アプリによって表示されるファイルをユーザーのホームにいつでも配置できます。

于 2009-06-02T17:09:34.037 に答える
1

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.

于 2009-06-01T20:54:32.953 に答える