您可以根据需要安装多个版本的Java。
修改本地环境变量(如JAVA_HOME)将是非常危险的,因为它可能引用现有的Java安装。
这与所谓的“平台依赖问题”无关。 😉
由于脚本可能依赖于JAVA_HOME来启动自身,因此对于修改JAVA_HOME的新Java安装来说,这将是灾难性的:所有这些脚本突然必须使用新的可能不兼容的JVM启动。
此外,通过在路径中设置$ JAVA_HOME / bin或%JAVA_HOME%/ bin,您可以将JAVA_HOME动态更改为任何要使用的Java版本,而不必与PATH变量相关。
Still, this does not explain why the installer does not set JAVA_HOME when it is not previously set at all.
答案很简单:
安装程序不知道脚本是否已经依赖于JAVA_HOME。
意义:某些脚本可以测试JAVA_HOME值,如果没有设置,请参考其他安装的JVM(不要忘记“安装”),只能引用“复制”:JDK / JRE并不总是由一个设置)
如果设置了JAVA_HOME,那么可能会中断某些脚本的默认行为。
Not wanting to disturb hypothetical scripts that depend on a env var not being set sound pointlessly paranoid to me – If a script does that, then it clearly WANTS to use a different JVM when one is installed – no reason to avoid that.
嗯…甜蜜为了处理日常的大量部署问题(对于我店内部的应用),我可以向你保证:这是非常理智的“偏执狂”
对待有
当您部署到(非常)大量的用户时,您不想对其平台和配置做任何假设。 “明显的WANTS”是我不敢做的假设(或者我将手机重定向到你的身上),你处理愤怒的电话)。
例如,我们有许多脚本启动了Sun的1.4.2 JVM(JAVA_HOME没有在开发平台上设置,默认路径直接在脚本中设置),或者与JRockit(JAVA_HOME集合)的1.4.2一样,因为它是预期的集成,预生产和生产平台的目标)。
但是我们定期安装新的JDK1.6.x,因为我们用它来启动eclipse。
假设那些脚本想要他们的JAVA_HOME设置,没有任何工作了。
You’re describing scripts that require one specific version, but still look at global JAVA_HOME. That’s just badly thought out scripts.
虽然这可能或可能不是真的,但这也正是我的观点:
“你不想做任何假设”:他们的平台/设置没有假设,也没有对他们的“最佳实践”的假设。
前者可能听起来很偏执,后者是普通常识:认为您的产品(这里是JDK设置)不会破坏用户环境中的任何内容,因为用户“正确地”认为他的脚本会变得疯狂。
GvS建议:
Or it could just have option to do it, disabled by default
这将意味着另一个选项可以包括在设置屏幕中,选项应由用户仔细检查,哪些可能会有意想不到的后果,即使用户选择它认为他知道他正在做什么…
这根本不值得。