2010-01-25 24 views
34

Nuestra empresa se actualizó recientemente de Windows XP a Windows 7 Enterprise. La instalación de JDK ya no configura user.home en la ruta completa del directorio de usuario, sino que establece user.home en %userprofile%. Esto está causando una gran cantidad de problemas con aplicaciones como Eclipse, Maven, etc. Ahora tengo que configurar -Duser.home en la JVM para cada aplicación. Alguien más ha experimentado esto? ¿Hay una solución para esto? ¿Esto estaría relacionado con la instalación de Windows 7 Enterprise? He probado el 1.5 JDK y el 1.6 JDK.Java user.home se establece en% userprofile% y no se resuelve

Aquí está la lista de propiedades. Nota user.home:

-- listing properties -- 
java.runtime.name=Java(TM) SE Runtime Environment 
sun.boot.library.path=C:\Program Files\Java\jre6\bin 
java.vm.version=16.0-b13 
java.vm.vendor=Sun Microsystems Inc. 
java.vendor.url=http://java.sun.com/ 
path.separator=; 
java.vm.name=Java HotSpot(TM) Client VM 
file.encoding.pkg=sun.io 
user.country=US 
sun.java.launcher=SUN_STANDARD 
sun.os.patch.level= 
java.vm.specification.name=Java Virtual Machine Specification 
user.dir=C:\Users\politesp\Desktop 
java.runtime.version=1.6.0_18-b07 
java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment 
java.endorsed.dirs=C:\Program Files\Java\jre6\lib\endorsed 
os.arch=x86 
java.io.tmpdir=C:\Users\politesp\AppData\Local\Temp\ 
line.separator= 

java.vm.specification.vendor=Sun Microsystems Inc. 
user.variant= 
os.name=Windows 7 
sun.jnu.encoding=Cp1252 
java.library.path=C:\WINDOWS\system32;.;C:\WINDOWS\Sun\... 
java.specification.name=Java Platform API Specification 
java.class.version=50.0 
sun.management.compiler=HotSpot Client Compiler 
os.version=6.1 
user.home=%userprofile% 
user.timezone= 
java.awt.printerjob=sun.awt.windows.WPrinterJob 
file.encoding=Cp1252 
java.specification.version=1.6 
user.name=politesp 
java.class.path=. 
java.vm.specification.version=1.0 
sun.arch.data.model=32 
java.home=C:\Program Files\Java\jre6 
java.specification.vendor=Sun Microsystems Inc. 
user.language=en 
awt.toolkit=sun.awt.windows.WToolkit 
java.vm.info=mixed mode, sharing 
java.version=1.6.0_18 
java.ext.dirs=C:\Program Files\Java\jre6\lib\ext;C:... 
sun.boot.class.path=C:\Program Files\Java\jre6\lib\resour... 
java.vendor=Sun Microsystems Inc. 
file.separator=\ 
java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... 
sun.cpu.endian=little 
sun.io.unicode.encoding=UnicodeLittle 
sun.desktop=windows 
sun.cpu.isalist=pentium_pro+mmx pentium_pro pentium+m... 

Actualización:

Usando el enlace con el fallo de Andreas_D descubrí:

El valor de HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop es % USERPROFILE% \ Desktop en mi instalación de Windows 7 Enterprise.

Cuando cambio el valor de esta clave a C:\Users\politesp\Desktop, mi user.home se resuelve correctamente. ¿Alguna idea de por qué está pasando esto?

+2

Esto está supuestamente arreglado en Java 8 ... http://bugs.sun.com/view_bug.do?bug_id=4787931 – Pureferret

Respuesta

25

La mayoría de las claves de registro ubicados en:

HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Shell Folders

comenzó con% userprofile%. Actualicé todas las claves de registro que comenzaron con% userprofile% para comenzar con C: \ Users \ myusername. Verifiqué en Windows XP que las rutas están de hecho codificadas y que% userprofile% no se usa. Los técnicos de TI mencionaron que las claves de registro predeterminadas usaban% profile de perfil de usuario debido a un perfil predeterminado que se usaba en Windows 7. La JVM espera que la ruta de Escritorio sea codificada. No evaluará las variables de entorno.

Puede actualizar las claves de registro una a una o puede exportar la carpeta y cambiar las claves.Así es como se puede exportar e importar las claves de registro:

1. Go to Start > Run. 
2. Type regedit. This opens the registry editor. 
3. Browse to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders. 
4. Right click on Shell Folders and choose Export. 
5. Select the Desktop as the destination and enter Shell Folders for the file name and save the file. 
6. Open the file in a text editor and replace %userprofile% with C:\\Users\\yourusername. Save and close the file. 
7. Go back to the registry editor window and select File > Import from the main menu. 
8. Select Shell Folders.reg and click Open. 
9. Close the registry editor and delete the Shell Folders.reg file off of the desktop. 
+2

Interesante cómo mucha gente todavía se pierde el aviso »No utilizar esta clave de registro« allí;) – Joey

+0

Buena investigación en su pregunta, y excelente seguimiento de la respuesta. Internet es mejor para este Q & A. – kevinarpe

10

Me parece que, por cualquier motivo, %USERPROFILE% no se ha establecido en un valor. ¿Qué obtienes si escribes echo %USERPROFILE% en el shell de comandos?

Quizás no sea una característica del sistema operativo sino un problema de configuración. En mi máquina (Vista) %USERPROFILE% resuelve a mi directorio home y es el mismo para la propiedad de Java user.home

Editar

Aquí hay un problema Vista/Windows7 con PERFIL_USUARIO y user.home: bug. no puede resolver su problema le puede dar una idea ..

+0

echo% PERFIL DE USUARIO% imprime C: \ Users \ politesp –

+0

tal vez es sensible a mayúsculas y minúsculas ? ¿Has probado USERPROFILE en lugar de userprofile? – kpolice

+0

al menos en VISTA, los nombres de las variables de entorno no distinguen entre mayúsculas y minúsculas. Y realmente dudo que MS haya cambiado eso con Windows 7 ... –

10

Hasta Java 8 en caso de fijación, la solución es añadir esta en las variables de entorno:
_JAVA_OPTIONS: -Duser.home =% HOMEDRIVE %% HOMEPATH%

o en línea de comandos:
conjunto _JAVA_OPTIONS = -Duser.home =% HOMEDRIVE %% HOMEPATH%

vi la solución en los comentarios de esta página: http://www.timehat.com/javas-user-home-is-wrong-on-windows/

1

valores de cadena individuales en el registro tienen 2 tipos "REG_SZ" y "REG_EXPAND_SZ" y tratan "%data%" cadenas de manera diferente.

Type "REG_SZ" leaves any "%data%" as is. 

Tipo "REG_EXPAND_SZ" reemplaza "%data%" la "data" valor de la variable medio ambiente si se defina otra cosa ninguna resolución se lleva a cabo.

Las miniaplicaciones de edición de variables de entorno de la GUI de Windows seleccionan el tipo correcto dependiendo de si "%name%" aparece en el campo de valor.

Este problema parece un instalador que toma malas decisiones al escribir en el registro.

Cuestiones relacionadas