java - instalar - install openjdk 8 ubuntu
Java: System.getProperty("user.home") devuelve "?" (8)
¿Qué pasa con las otras propiedades garantizadas? ¿Qué sucede si haces una llamada a algo como lo siguiente?
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) + "''.");
}
Estoy completamente perdido en este: System.getProperty("user.home") y System.getProperty("user.name") devuelve un questionmark "?".
System-Specs:
Kubuntu 9.04
Gnome 2.2.61
Java 1.5.0_16
Mi caso de prueba se ve así:
$ more Test.java
class Test { public static void main( String[] args ) { System.out.println( System.getProperties() ); } }
El resultado es (saltos de línea agregados para una mejor legibilidad, nombre de compañía reemplazado y nombre propio):
$ 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=
}
¿Alguien alguna vez experimentó eso? ¿Dónde busca Java buscar el usuario y el directorio particular? Ya revisé la variable de entorno HOME que está configurada correctamente.
Es un poco embarazoso, pero la solución fue simplemente usar un JDK de 64 bits en un sistema de 64 bits. Copié todo de mi máquina anterior, lo que significaba también un JDK de 32 bits, y este era el problema. Funcionó como se esperaba con un tiempo de ejecución de 64 bits.
Perdón por molestar.
Eso es realmente interesante. Parece que la propiedad user.home no está tomada de la variable de entorno $ HOME. He intentado esto:
$ echo $HOME && java Test && unset HOME && echo $HOME && java Test
/home/grzole
/home/grzole
/home/grzole
Tenga en cuenta que el shell olvida el valor de la variable HOME, pero Java no lo hace.
EDITAR: sospecho que Java solo toma el /home/ prefix y agrega el nombre de usuario. Considera esto:
# adduser b
...
# rm -fr /home/b
# su - b
No directory, logging in with HOME=/
$ cd /tmp/jb
$ java Test
/home/b
¿Quizás no tienes el directorio /home en tu sistema de archivos?
Necesitamos estudiar detenidamente el código nativo para descubrir qué está pasando exactamente. La variable user.home está configurada por los módulos "PAM" en sistemas Linux y si el módulo en uso genera estos dinámicamente y la implementación de Java está tratando de obtener el valor sin utilizar PAM explícitamente, entonces el comportamiento es impredecible, por lo tanto, el "?"
Para completar, también parece que, si el sistema en cuestión está configurado para usar la autenticación LDAP (y no / etc / passwd), entonces el problema descrito en este informe de error puede ser el problema: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6972329 . Asegúrese de que está instalado el libnss_ldap.so apropiado para su sistema (por ejemplo: una biblioteca LDAP de 32 bits para usar con Java de 32 bits). Algunos comandos que podrían ser útiles para determinar esto podrían ser:
> 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!
Una solución alternativa, no una solución. Debería poder configurarlo agregando -Duser.home=$HOME como argumento.
java -Duser.home=$HOME Test
Yo tuve el mismo problema. Como se mencionó anteriormente, el problema es que la Java de 32 bits también necesita las bibliotecas de ldap de 32 bits para instalarse. Si no, se produce el error descrito.
La instalación de libnss_ldap.so.2 y los paquetes dependientes resuelven el problema.
wds tiene razón en su comentario. El valor de user.home parece estar tomado de / etc / passwd. ¿Cuál es su línea en /etc/passwd para su usuario?
Si cambié la entrada a /home/nonexisting , la clase de Test imprimió /home/nonexisting . ¿Lo tienes ? en / etc / passwd?