Java: Система.метод getproperty("пользователя.home") returns"?"

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

System-Specs:
Kubuntu 9.04
Gnome 2.2.61
Java 1.5.0_16

мой testcase выглядит так:

$ 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 ищет пользователя и домашний каталог? Я уже проверил переменную домашней среды, которая установлена правильно.

8 ответов


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

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


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

java -Duser.home=$HOME Test

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


   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) + "'.");
    }


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

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


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

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

/home/grzole

обратите внимание, что оболочка забывает значение домашней переменной, но Java этого не делает.

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

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

может быть, у вас нет /home каталог в файловой системе вообще?


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


для полноты картины, он также выглядит, если система настроена на использование проверки подлинности LDAP (а не в /etc/passwd С), то этот вопрос описано в сообщении об ошибке может быть проблема: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6972329. Убедитесь, что соответствующие libnss_ldap.так, установленные для вашей системы (например: 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!

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

установка libnss_ldap.Итак.2 и зависящие пакеты решают проблему.