Je suis complètement perdu sur celui-ci: System.getProperty("user.home")
et System.getProperty("user.name")
renvoie un questionnaire "?".
System-Specs:
Kubuntu 9.04
Gnome 2.2.61
Java 1.5.0_16
Ma témoignage ressemble à ça:
$ more Test.Java
class Test { public static void main( String[] args ) { System.out.println( System.getProperties() ); } }
Le résultat est (ajouté des pauses de ligne pour une meilleure lisibilité, le nom de la société remplacé et le nom propre):
$ 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=
}
Est-ce que quelqu'un a déjà expérimenté cela? Où est Java <Cherche à trouver le répertoire utilisateur et domestique? J'ai déjà vérifié la variable d'environnement domestique qui est définie correctement.
C'est un peu embarrassant, mais la solution consistait simplement à utiliser un JDK 64 bits sur un système 64 bits. J'ai tout copié de mon ancienne machine, qui signifiait aussi un JDK 32 bits, et c'était le problème. Cela a fonctionné comme prévu avec un temps d'exécution 64 bits.
Désolé pour le dérangement.
Une solution de contournement, pas une solution. Vous devriez être capable de le définir en ajoutant -Duser.home=$HOME
comme un argument.
Java -Duser.home=$HOME Test
wDS a raison dans son commentaire. Les user.home
la valeur semble être prise de/etc/passwd. Quelle est votre ligne dans /etc/passwd
Pour votre utilisateur?
Si j'ai changé l'entrée en /home/nonexisting
, le Test
classe imprimée /home/nonexisting
. Est-ce que vous avez ?
In/etc/passwd?
Besoin de porser le code natif pour déterminer ce qui se passe exactement. L'utilisateur.Home variable est défini par les modules "PAM" dans les systèmes Linux et si le module utilisé génère ces éléments de manière dynamique et le Java implémentation tente d'obtenir la valeur sans explicitement utiliser PAM. Le comportement est imprévisible d'où le "?"
Pour être complet, il semble aussi que, si le système en question est configuré pour utiliser l'authentification LDAP (et non/etc/passwd), la question décrite dans le présent rapport de bogue peut être le problème: http: // bogues .Java.com/bugdatabase/view_bug.do? bug_id = 6972329 . Assurez-vous que le libnss_ldap.so approprié est installé pour votre système (par exemple .: une bibliothèque LDAP 32 bits pour une utilisation avec Java 32 bits). Certaines commandes qui pourraient être utiles pour déterminer cela pourrait être:
> 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!
C'est vraiment intéressant. Ressemble à user.home
La propriété n'est pas extraite de la variable d'environnement $ à domicile. J'ai essayé ceci:
$ echo $HOME && Java Test && unset HOME && echo $HOME && Java Test
/home/grzole
/home/grzole
/home/grzole
Notez que la coque oublie la valeur de la variable domestique, mais Java pas.
Edit: je soupçonne Java il suffit de prendre le /home/
Préfixe et ajoute le nom d'utilisateur. Considère ceci:
# adduser b
...
# rm -fr /home/b
# su - b
No directory, logging in with HOME=/
$ cd /tmp/jb
$ Java Test
/home/b
Peut-être que vous n'avez pas le /home
répertoire dans votre système de fichiers du tout?
J'ai eu le même problème. Comme mentionné ci-dessus, le problème est que le 32 bit Java a également besoin des bibliothèques 32 bits LDAP à installer. Sinon, l'erreur décrite se produit.
L'installation du libnss_ldap.so.2 et des packages en fonction résout le problème.