Java System.getProperty ("user.dir") в Mac OS X - PullRequest
Новая
       34

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

0 голосов
/ 02 июня 2009

У меня есть пакет приложений на Mac OS X 10.4 на рабочем столе. Мое приложение ищет папку с именем «resources», в которой хранятся файлы, которые будут отображаться (хранятся в том же месте, что и исполняемый JAR). Я знаю, что в комплекте приложений также есть папка с именем «Ресурсы», извините, если это сбивает с толку, но я никогда не программировал на Mac и не знал, что это будет то же имя.

В Windows, когда я звоню System.getProperty("user.dir"), я получаю местоположение, в котором находится исполняемый файл JAR. Именно то, что я хотел.

Почему тогда, когда я запускаю комплект приложений, getProperty возвращает "/"? Это все. Я ожидал, что он выдаст что-то вроде "/Users/user_name/Desktop"..., где находится мой комплект приложений.

Ответы [ 2 ]

1 голос
/ 02 июня 2009

Вместо этого я использовал системное свойство "user.home" вместо "user.dir". Таким образом, мне не нужно беспокоиться о том, куда смотрит JVM. У меня есть пакет приложения, который ссылается на мой файл jar напрямую, используя скрипт bash в качестве исполняемого файла, вызываемого файлом info.plist. я всегда могу разместить файлы, которые будут отображаться приложением, у себя дома, потому что это местоположение всегда будет возвращать путь.

1 голос
/ 02 июня 2009

Это потому, что «user.dir» указывает текущий каталог пользователя, действующий при запуске JVM; в Windows это часто местоположение JAR, если не указано иное. В OSX вполне может отсутствовать концепция текущего каталога, но, скорее всего, он просто имеет другое значение по умолчанию.

Хотя я никогда специально не тестировал этот код под OSX, вы можете попробовать это, чтобы найти каталог, из которого был загружен любой класс: 

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

он надежно работал для меня годами под Windows для всех версий Java начиная с Java 1.

...