为什么 Java SDK 安装程序不设置 JAVA_HOME？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/560797/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why doesn't the Java SDK installer set JAVA_HOME?
提问by compie
I always wondered why I have to manually set the JAVA_HOME environment variable after installing the Java SDK.
我一直想知道为什么安装Java SDK后必须手动设置JAVA_HOME环境变量。
JAVA_HOME=c:\Program Files\Java\jdk1.6.0_12
JAVA_HOME=c:\Program Files\Java\jdk1.6.0_12
Visual Studio at least provides a batch file to set these kind of environment variables:
Visual Studio 至少提供了一个批处理文件来设置这些类型的环境变量：
call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
调用“c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.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.
Java 有类似的东西吗？我正在尝试制作一个构建脚本，该脚本在安装 Java SDK 后应该可以简单地工作。我不希望人们在他们的 PC 上弄乱环境变量。
采纳答案by VonC
You can install as many versions of Java as you like.
您可以根据需要安装任意数量的 Java 版本。
It would be dangerous for the setup to modify a localenvironment variable such as JAVA_HOME, since it might reference an existing Java installation.
安装程序修改本地环境变量（例如 ）会很危险JAVA_HOME，因为它可能会引用现有的 Java 安装。
This has nothing to do with an alleged "platform dependent issue". ;)
这与所谓的“平台相关问题”无关。;)
Since scripts might depend on JAVA_HOMEto 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.
由于脚本可能依赖于JAVA_HOME自己启动，再次，这对于要修改的新 Java 安装来说将是灾难性的JAVA_HOME：所有这些脚本将突然必须使用可能不兼容的新 JVM 启动。
Plus, by setting $JAVA_HOME/binor %JAVA_HOME%/binin your path, you can dynamically change JAVA_HOMEto whatever version of Java you want to use without having to much with your PATH variable.
另外，通过设置$JAVA_HOME/bin或%JAVA_HOME%/bin在您的路径中，您可以动态更改JAVA_HOME为您想要使用的任何 Java 版本，而无需过多使用 PATH 变量。
Michael Borgwardthas made in the comments the interesting followup's question
迈克尔·博格沃特 (Michael Borgwardt) 在评论中提出了有趣的后续问题
Still, this does not explain why the installer does not set JAVA_HOME when it is not previously set at all.
尽管如此，这并不能解释为什么安装程序在之前根本没有设置的情况下不设置 JAVA_HOME。
The answer is simple:
答案很简单：
The setup cannot know if a script already depends on JAVA_HOMEor not.
该设置可以不知道，如果一个脚本已经依赖于JAVA_HOME与否。
Meaning: some scripts could test for JAVA_HOMEvalue, 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)
含义：某些脚本可以测试JAVA_HOME值，如果未设置，则引用安装在其他地方的另一个 JVM（不要忘记，通过“安装”，只能引用“复制”：JDK/JRE 并不总是由安装设置）
If you set JAVA_HOME, that can disrupt the default behavior of some of your scripts.
如果您设置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.
不想打扰依赖于未设置 env var 的假设脚本对我来说听起来毫无意义的偏执 - 如果脚本这样做，那么它显然希望在安装时使用不同的 JVM - 没有理由避免这种情况。
Mmm... Sweet. For dealing with massive deploymentissues 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_HOMEset, as it is the intended target on integration, pre-production and production platforms).
例如，我们有许多脚本使用来自 sun 的 1.4.2 JVM（开发平台上未设置 JAVA_HOME，直接在脚本中设置默认路径）或使用来自 JRockit 的 1.4.2（JAVA_HOME设置，因为它是预期目标在集成、预生产和生产平台上）。
But we install regularly the new JDK1.6.x since we use it for launching eclipse.
但是我们定期安装新的JDK1.6.x，因为我们用它来启动eclipse。
Assume that those scripts want their JAVA_HOMEset... and nothing works anymore.
假设这些脚本想要它们的JAVA_HOME集合......并且没有任何作用了。
... To which Robert Grantmakes 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.
您正在描述需要一个特定版本的脚本，但仍然查看全局 JAVA_HOME。那只是经过深思熟虑的脚本。
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.
虽然这可能是真的，也可能不是，但这也正好说明了我的观点：
“你不想做任何假设”：不对他们的平台/设置做任何假设，也不对他们的“最佳实践”做任何假设。
前者可能听起来很偏执，后者是普通常识：认为您的产品（这里是 JDK 设置）不会破坏用户环境中的任何内容，因为用户“正确”地考虑了他的脚本......这将是疯狂的。
GvSsuggests:
GvS建议：
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.
这根本不值得。
回答by tehvan
I guess java doesn't want to do anything which is platform-dependent. In Windows, classpaths are set differently from LINUX/UNIX.
我猜 java 不想做任何依赖于平台的事情。在 Windows 中，类路径的设置与 LINUX/UNIX 不同。
回答by Rolf
I'm not sure why this is, because the installers clearly solve platform dependant issues (which is ofcourse the whole point of a JVM). Are you sure you aren't mixing the JRE with the JSDK?
我不确定为什么会这样，因为安装程序清楚地解决了平台相关问题（这当然是 JVM 的全部意义所在）。您确定没有将 JRE 与 JSDK 混合使用吗？
Maybe there's a way for your program to search where java is installed (that would be a script I guess), and then set JAVA_HOME and possibly add it to the path.
也许有一种方法可以让您的程序搜索安装 java 的位置（我猜这将是一个脚本），然后设置 JAVA_HOME 并可能将其添加到路径中。
IBM seems to be doing this trick already: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21199220
IBM 似乎已经在做这个把戏了：http: //www-01.ibm.com/support/docview.wss?rs=180&uid= swg21199220
Other interesting post hinting at the difference between JRE and JSDK installations: http://confluence.atlassian.com/display/CONF26/Set+JAVA_HOME+variable+in+Windows
其他有趣的帖子暗示了 JRE 和 JSDK 安装之间的区别：http: //confluence.atlassian.com/display/CONF26/Set+JAVA_HOME+variable+in+Windows
Hope this helps.
希望这可以帮助。
回答by Michael Borgwardt
I don't think JAVA_HOME is a convention invented or supported by Sun.
我不认为 JAVA_HOME 是 Sun 发明或支持的约定。
They probably remember the fiasco that was the CLASSPATH environment variable** all too well and prefer to stay the hell away from environment variables.
他们可能对 CLASSPATH 环境变量 ** 的惨败记忆犹新，并且宁愿远离环境变量。
** This was encouraged as the primary way to set the JVM classpath in earlier Java SDKs and literature, and resulted in the user and various applications messing with the environment variable, overwriting each other's changes and depending on mutually contradictive contents.
** 这在早期的 Java SDK 和文献中被鼓励作为设置 JVM 类路径的主要方式，并导致用户和各种应用程序混淆环境变量，覆盖彼此的更改并依赖于相互矛盾的内容。
回答by McDowell
The vcvarsall.batmechanism is a convenient way for Visual C++ to provide a console with the correct variables without messing with the user's/system's environment variables. However, it assumes that Installshield is the only way to get code onto the system. The JDK should tolerate being cut'n'pasted from one location to another.
该vcvarsall.bat机制是Visual C ++一个便捷的方式为用户提供正确的变量控制台而不与用户/系统的环境变量搞乱。但是，它假定 Installshield 是将代码导入系统的唯一方法。JDK 应该容忍从一个位置剪切到另一个位置。
If you're looking for java.exe, the Installshield installer should put it in %windir%\system32, so it is available on the PATH.
如果您正在寻找java.exe，Installshield 安装程序应该将它放在%windir%\system32 中，以便它在 PATH 上可用。
You can gain some hints about the location of installed apps by querying the registry:
您可以通过查询注册表获得有关已安装应用程序位置的一些提示：
C:>REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit.6" /v JavaHome
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit.6
JavaHome REG_SZ C:\dev\Java\jdk1.6.0_05
However, you can't rely on this absolutely because this makes some assumptions about vendor, version and installation mechanism.
但是，您不能绝对依赖于此，因为这对供应商、版本和安装机制做出了一些假设。
回答by Allan Miller
This may help someone else out who ends up here like me. I just want to use Java as a tool, not adopt it as a way of life, so I only needed to know how JAVA_HOME was getting set and why it was not correct. The answer turned out to be that the WinAnt installation sets JAVA_HOME (along with ANT_HOME), but only based on the currently installed Java. So if you need to change the version of Java, and you are using Ant, the correct way to do it is to uninstall WinAnt, uninstall Java, install the new Java, and then reinstall WinAnt.
这可能会帮助像我一样最终来到这里的其他人。我只是想将 Java 用作工具，而不是将其用作一种生活方式，因此我只需要知道 JAVA_HOME 是如何设置的以及为什么它不正确。答案原来是 WinAnt 安装设置了 JAVA_HOME（连同 ANT_HOME），但仅基于当前安装的 Java。因此，如果您需要更改Java 版本，并且您使用的是Ant，那么正确的做法是卸载WinAnt，卸载Java，安装新的Java，然后重新安装WinAnt。
