为什么 Java SDK 安装程序不设置 JAVA_HOME?
我一直在想，为什么我在安装 Java SDK 后必须手动设置 JAVA_HOME 环境变量.
<块引用>JAVA_HOME=c:Program FilesJavajdk1.6.0_12
Visual Studio 至少提供了一个批处理文件来设置这些环境变量:
<块引用>调用c:Program FilesMicrosoft VisualStudio 9.0VCvcvarsall.bat"
Java 有类似的东西吗?我正在尝试制作一个在安装 Java SDK 后应该可以正常工作的构建脚本.我不希望人们在他们的 PC 上弄乱环境变量.
解决方案您可以安装任意多个版本的 Java.
安装程序修改 本地 环境变量(例如 JAVA_HOME)会很危险，因为它可能会引用现有的 Java 安装.
这与所谓的平台相关问题"无关.;)
由于脚本可能依赖于 JAVA_HOME 来启动自己，再次，这对于新的 Java 安装来修改 JAVA_HOME 将是灾难性的:所有这些脚本都必须突然使用新的可能不兼容的 JVM 启动.
另外，通过在路径中设置 $JAVA_HOME/bin 或 %JAVA_HOME%/bin，您可以将 JAVA_HOME 动态更改为任何版本您想要使用的 Java，而不必过多使用 PATH 变量.
Michael Borgwardt 在评论中提出了有趣的后续问题
<块引用>不过，这并不能解释为什么安装程序在以前根本没有设置 JAVA_HOME 时没有设置它.
答案很简单:
设置无法知道脚本是否已经依赖于JAVA_HOME.
含义:一些脚本可以测试JAVA_HOME的值，如果没有设置，则引用另一个安装在别处的JVM(不要忘记安装"只能引用复制": JDK/JRE 并不总是由安装程序安装)
如果您设置 JAVA_HOME，则可能会破坏某些脚本的默认行为.
不想打扰那些依赖于未设置环境变量的假设脚本对我来说听起来毫无意义的偏执 - 如果脚本这样做，那么它显然希望在安装时使用不同的 JVM - 没有理由避免这种情况.
嗯...甜蜜.对于每天处理大量部署问题(用于我店的内部应用程序)，我可以向您保证:这是非常理智的偏执狂"对待拥有.
当您部署到(非常)大量用户时，您不想对他们的平台和配置做出任何假设.显然想要"是我不敢做出的假设(或者我将手机重定向到您的手机；)并且您处理愤怒的电话).
例如，我们有许多脚本使用 sun 的 1.4.2 JVM(开发平台上未设置 JAVA_HOME，直接在脚本中设置默认路径)或 JRockit 的 1.4.2(JAVA_HOME 集，因为它是集成、预生产和生产平台的预期目标).
但我们会定期安装新的 JDK1.6.x，因为我们使用它来启动 eclipse.
假设那些脚本想要他们的 JAVA_HOME 设置...并且没有任何工作了.
... Robert Grant 对此进行了现场评论:
<块引用><块引用>您正在描述需要一个特定版本的脚本，但仍需查看全局 JAVA_HOME.这只是经过深思熟虑的脚本.
虽然这可能是真的，也可能不是，但这也准确地说明了我的观点:
你不想做任何假设":不假设他们的平台/设置，也不假设他们的最佳实践".
前者可能听起来偏执，后者是普通常识:认为您的产品(这里是 JDK 设置)不会破坏用户环境中的任何内容，因为用户正确"地考虑了他的脚本......这太疯狂了.
GvS 建议:
<块引用>或者它可以选择执行此操作，默认禁用
这意味着在设置屏幕中包含另一个选项，该选项应由用户仔细查看，并且可能会产生意想不到的后果，即使用户选择它时认为他知道自己在做什么......
这根本不值得.
I always wondered why I have to manually set the JAVA_HOME environment variable after installing the Java SDK.
JAVA_HOME=c:Program FilesJavajdk1.6.0_12
Visual Studio at least provides a batch file to set these kind of environment variables:
call "c:Program FilesMicrosoft Visual Studio 9.0VCvcvarsall.bat"
Does Java have something similar? I'm trying to make a build script that should simply work after installing the Java SDK. I don't want people to mess with environment variables on their PC.
解决方案You can install as many versions of Java as you like.
It would be dangerous for the setup to modify a local environment variable such as JAVA_HOME, since it might reference an existing Java installation.
This has nothing to do with an alleged "platform dependent issue". ;)
Since scripts might depend on JAVA_HOME to launch themselves, again, this would be disasterous for a new Java install to modify JAVA_HOME: all those scripts would suddenly have to be launched with a new potentially incompatible JVM.
Plus, by setting $JAVA_HOME/bin or %JAVA_HOME%/bin in your path, you can dynamically change JAVA_HOME to whatever version of Java you want to use without having to much with your PATH variable.
Michael Borgwardt has made in the comments the interesting followup's question
Still, this does not explain why the installer does not set JAVA_HOME when it is not previously set at all.
The answer is simple:
The setup cannot know if a script already depends on JAVA_HOME or not.
Meaning: some scripts could test for JAVA_HOME value, and if not set, refer to another JVM installed elsewhere (and do not forget that by "install", one can only refer to "copied": a JDK/JRE is not always installed by a setup)
If you set JAVA_HOME, that can disrupt the default behavior of some of your scripts.
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.
Mmm... Sweet. For dealing with massive deployment issues on a daily-basis (for internal application in my shop), I can assure you: it is very sane "paranoid"
treat to have.
When you deploy to a (very) large set of users, you do not want to make any assumption about their platform and configurations. "clearly WANTS" is an assumption I would not dare to make (or I redirect my phone to yours ;) and you handle the angry calls).
For instance, we have many scripts which launches with a 1.4.2 JVM from sun (JAVA_HOME not set on development platform, default path set directly in the script), or with 1.4.2 from JRockit (JAVA_HOME set, as it is the intended target on integration, pre-production and production platforms).
But we install regularly the new JDK1.6.x since we use it for launching eclipse.
Assume that those scripts want their JAVA_HOME set... and nothing works anymore.
... To which Robert Grant makes this on-the-spot critic:
You're describing scripts that require one specific version, but still look at global JAVA_HOME. That's just badly thought out scripts.
While that may or may not be true, that also illustrates precisely my point:
"you do not want to make any assumption": no assumption on their platform/settings, and no assumption on their "best practices".
The former may sound paranoid, the latter is plain common-sense: thinking that your product (here a JDK setup) will not break anything on the user's environment because the user has "correctly" thought out his scripts... would be insane.
GvS suggests:
Or it could just have option to do it, disabled by default
That would mean another option to include in the setup screens, option which should be carefully reviewed by the user, and which may have unintended consequences, even when the user selects it thinking he knows what he is doing...
It is simply not worth it.