Java: System.getProperty ("user.home") возвращает "?" - PullRequest
23 голосов
/ 01 октября 2009

Я полностью потерян на этом: System.getProperty("user.home") и System.getProperty("user.name") возвращает вопросительный знак "?".

System-Specs:
Kubuntu 9.04
Gnome 2.2.61
Java 1.5.0_16

Мой тестовый пример выглядит так:

$ more Test.java
class Test { public static void main( String[] args ) { System.out.println( System.getProperties() ); } }

Результат (добавлены разрывы строк для лучшей читаемости, заменено название компании и собственное имя):

$ javac Test.java
$ java Test
{
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition,
sun.boot.library.path=/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/i386,
java.vm.version=1.5.0_16-b02,
java.vm.vendor=Sun Microsystems Inc.,
java.vendor.url=http://java.sun.com/,
path.separator=:,
java.vm.name=Java HotSpot(TM) Server VM,
file.encoding.pkg=sun.io,
sun.java.launcher=SUN_STANDARD,
user.country=US,
sun.os.patch.level=unknown,
java.vm.specification.name=Java Virtual Machine Specification,
user.dir=/home/MYCOMPANY/myname/temp,
java.runtime.version=1.5.0_16-b02,
java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment,
java.endorsed.dirs=/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/endorsed,
os.arch=i386,
java.io.tmpdir=/tmp,
line.separator=
,
java.vm.specification.vendor=Sun Microsystems Inc.,
os.name=Linux,
sun.jnu.encoding=UTF-8,
java.library.path=/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/i386/server:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/i386:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/../lib/i386,
java.specification.name=Java Platform API Specification,
java.class.version=49.0,
sun.management.compiler=HotSpot Server Compiler,
os.version=2.6.28-15-generic,
user.home=?,
user.timezone=,
java.awt.printerjob=sun.print.PSPrinterJob,
file.encoding=UTF-8,
java.specification.version=1.5,
java.class.path=.,
user.name=?,
java.vm.specification.version=1.0,
java.home=/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre,
sun.arch.data.model=32,
user.language=en,
java.specification.vendor=Sun Microsystems Inc.,
java.vm.info=mixed mode,
java.version=1.5.0_16,
java.ext.dirs=/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/ext,
sun.boot.class.path=/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/rt.jar:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/i18n.jar:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/sunrsasign.jar:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/jsse.jar:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/jce.jar:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/lib/charsets.jar:/home/MYCOMPANY/myname/apps/jdk1.5.0_16/jre/classes,
java.vendor=Sun Microsystems Inc.,
file.separator=/,
java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi,
sun.io.unicode.encoding=UnicodeLittle,
sun.cpu.endian=little,
sun.desktop=gnome,
sun.cpu.isalist=
}

Кто-нибудь когда-либо испытывал это? Где Java ищет пользовательский и домашний каталог? Я уже проверил переменную окружения HOME, которая установлена ​​правильно.

Ответы [ 8 ]

30 голосов
/ 02 октября 2009

Это немного смущает, но решение было просто использовать 64-битный JDK в 64-битной системе. Я скопировал все со своей старой машины, что означало также 32-битный JDK, и это было проблемой. Это работало как ожидалось с 64-битной средой выполнения.

Извините за беспокойство.

8 голосов
/ 01 октября 2009

Обходной путь, а не решение. Вы должны иметь возможность установить его, добавив -Duser.home=$HOME в качестве аргумента.

java -Duser.home=$HOME Test
3 голосов
/ 01 октября 2009

А как насчет других гарантированных свойств? Что произойдет, если вы сделаете звонок на что-то вроде следующего?


   public static void printAllGuaranteedProperties() {
       printAProperty ("java.version", "Java version number");
       printAProperty ("java.vendor", "Java vendor specific string");
       printAProperty ("java.vendor.url", "Java vendor URL");
       printAProperty ("java.home", "Java installation directory");
       printAProperty ("java.class.version", "Java class version number");
       printAProperty ("java.class.path", "Java classpath");
       printAProperty ("os.name", "Operating System Name");
       printAProperty ("os.arch", "Operating System Architecture");
       printAProperty ("os.version", "Operating System Version");
       printAProperty ("file.separator", "File separator");
       printAProperty ("path.separator", "Path separator");
       printAProperty ("line.separator", "Line separator");
       printAProperty ("user.name", "User account name");
       printAProperty ("user.home", "User home directory");
       printAProperty ("user.dir", "User's current working directory");
    }
    public static void printAProperty (String propName, String desc) {
       System.out.println ("Value for '" + desc + "' is '" + System.getProperty(propName) + "'.");
    }

2 голосов
/ 01 октября 2009

wds прямо в своем комментарии. Значение user.home, похоже, взято из / etc / passwd. Какова ваша строка в /etc/passwd для вашего пользователя?

Если я изменил запись на /home/nonexisting, класс Test напечатает /home/nonexisting. У вас есть ? в / etc / passwd?

1 голос
/ 03 февраля 2014

Для полноты картины также выглядит так: если рассматриваемая система настроена на использование аутентификации LDAP (а не / etc / passwd), то проблема, описанная в этом отчете об ошибке, может быть проблемой: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6972329. Убедитесь, что для вашей системы установлен соответствующий libnss_ldap.so (например, 32-битная библиотека LDAP для использования с 32-битной Java). Вот некоторые команды, которые могут быть полезны для определения этого:

> rpm -qa | grep ldap
nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64   # Note x86_64 bit version installed

> ls -l /lib64/libnss_ldap*
-rwxr-xr-x. 1 root root 44328 Jan  3  2012 /lib64/libnss_ldap.so.2
# ^^^ note 64 bit version installed.

> ls /lib/libnss_ldap*
ls: cannot access /lib/libnss_ldap*: No such file or directory
# ^^^ Indicates 32 bit version is not installed!
1 голос
/ 01 октября 2009

Нужно порыться в нативном коде, чтобы выяснить, что именно происходит. Переменная user.home устанавливается модулями "PAM" в системах Linux, и если используемый модуль генерирует их динамически, а реализация Java пытается получить значение без явного использования PAM, то поведение непредсказуемо, поэтому "?"

1 голос
/ 01 октября 2009

Это действительно интересно. Похоже, свойство user.home не взято из переменной окружения $ HOME. Я пробовал это:

$ echo $HOME && java Test && unset HOME && echo $HOME && java Test
/home/grzole
/home/grzole

/home/grzole

Обратите внимание, что оболочка забывает значение переменной HOME, а Java - нет.

EDIT: Я подозреваю, что Java просто берет префикс /home/ и добавляет имя пользователя. Учтите это:

# adduser b
...
# rm -fr /home/b
# su - b
No directory, logging in with HOME=/
$ cd /tmp/jb
$ java Test
/home/b

Может, у вас вообще нет директории /home в вашей файловой системе?

0 голосов
/ 10 октября 2014

У меня была такая же проблема. Как уже упоминалось выше, проблема в том, что для 32-битной Java также необходимо установить 32-битные библиотеки ldap. Если нет, то возникает описанная ошибка.

Установка libnss_ldap.so.2 и соответствующих пакетов решает проблему.

...