Puede instalar tantas versiones de Java como desee.
que sería peligroso para la configuración para modificar una variable local de entorno como JAVA_HOME, ya que podría hacer referencia a una instalación existente de Java.
Esto no tiene nada que ver con un supuesto "problema dependiente de la plataforma". ;)
Desde guiones pueden depender de JAVA_HOME para lanzarse, una vez más, esto sería desastroso para una nueva instalación de Java para modificar JAVA_HOME: todos esos guiones de repente tiene que ser puesto en marcha con una nueva JVM potencialmente incompatibles.
Además, mediante el establecimiento de $JAVA_HOME/bin o %JAVA_HOME%/bin en su camino, se puede cambiar dinámicamente JAVA_HOME a cualquier versión de Java que desea utilizar sin tener que gran parte de la variable PATH.
Michael Borgwardt ha hecho en los comentarios a la pregunta del seguimiento interesante
Sin embargo, esto no explica por qué el instalador no se establece JAVA_HOME cuando no se establece previamente en absoluto.
La respuesta es sencilla:
La configuración no se puede saber si un guión ya depende de JAVA_HOME o no.
Significado: algunos scripts podrían probar el valor JAVA_HOME, y si no están configurados, consulte otra JVM instalada en otro lugar (y no olvide que por "instalar", solo se puede hacer referencia a "copiado": JDK/JRE es no siempre instalado por una configuración)
Si configura JAVA_HOME, eso puede interrumpir el comportamiento predeterminado de algunos de sus scripts.
No queriendo molestar a los guiones hipotéticos que dependen de un env var no está establecido sonido sin sentido paranoico para mí - Si un script hace eso, entonces claramente quiere utilizar una JVM diferente cuando uno instalado - no hay razón para evitar eso.
Mmm ... dulce. Para tratar con el despliegue masivo cuestiones en un diario-base (para su aplicación interna en mi tienda), les puedo asegurar que: es muy sano "paranoica" delicia tener.
Al implementar en un grupo (muy) grande de usuarios, no desea hacer ninguna suposición sobre su plataforma y configuraciones. "claramente QUIERE" es una suposición que no me atrevería a hacer (o redirijo mi teléfono a la tuya;) y usted maneja las llamadas enojadas).
Por ejemplo, tenemos muchas secuencias de comandos que se inician con una JVM 1.4.2 desde sol (JAVA_HOME no establecido en la plataforma de desarrollo, ruta predeterminada establecida directamente en la secuencia de comandos) o con 1.4.2 desde JRockit (JAVA_HOME conjunto, como es el objetivo previsto en las plataformas de integración, preproducción y producción).
Pero instalamos regularmente el nuevo JDK1.6.x ya que utilizamos para el lanzamiento de Eclipse.
Supongamos que esos guiones quieren que su conjunto JAVA_HOME ... y nada funciona más.
... A lo que hace que este Robert Grant crítico sobre el terreno:
Estás describiendo las secuencias de comandos que requieren una versión específica, pero todavía miran JAVA_HOME global. Eso es solo guiones mal pensados.
Mientras que puede o no puede ser cierto, que también ilustra precisamente mi punto:
"que no quieren hacer ninguna suposición": ninguna suposición sobre su plataforma/ajustes, y ninguna suposición sobre su "mejores prácticas".
El primero puede sonar paranoico, este último es llano sentido común: pensar que su producto (en este caso una instalación de JDK) no va a romper nada en el entorno del usuario porque el usuario tiene "correctamente" pensado sus guiones ... sería insano.
GvS sugiere:
o simplemente podría tener la opción de hacerlo, desactivado por defecto
Eso significaría otra opción para incluir en las pantallas de configuración, opción que debería ser cuidadosamente revisado por el usuario, y que puede tener consecuencias no deseadas, incluso cuando el usuario lo selecciona pensando que sabe lo que está haciendo ...
Simplemente no vale la pena.
Porque Java no lo necesita. – EJP