对于基于 Linux OpenJDK Debian 的发行版,JAVA_HOME 环境变量的正确目标是什么?
在 Windows 中,JAVA_HOME
必须指向 JDK 安装文件夹(以便 JAVA_HOME/bin
包含所有可执行文件,JAVA_HOME/libs
包含所有默认 >jar
库)。
如果我下载 Sun 的 JDK 捆绑包并将其安装在 Linux 中,则过程相同。
但是,我需要使用 Kubuntu 的默认 OpenJDK 包。 问题是所有可执行文件都放在 /usr/bin
中。 但 jar 放在 /usr/share/java
中。 由于它们不在同一个 JAVA_HOME
文件夹下,我在使用 Grails 时遇到了问题,并且可能在使用其他需要标准 Java 结构的应用程序时也会遇到问题。
如果我使用:
JAVA_HOME=/usr
所有想要使用任何 Java 可执行文件的应用程序和脚本都可以使用标准过程
调用 $JAVA_HOME/bin/executable
。 但是,由于 jar 位于不同的位置,因此并不总是能找到它们(例如:在 grails 中,我得到native2ascii
的ClassDefNotFound
)。另一方面,如果我使用:
JAVA_HOME=/usr/share/java
找不到任何 Java 可执行文件(
java
、javac
等)。
那么,在基于 Debian 的 Linux 中处理 JAVA_HOME 变量的正确方法是什么?
感谢您的帮助, 路易斯
In Windows, JAVA_HOME
must point to the JDK installation folder (so that JAVA_HOME/bin
contains all executables and JAVA_HOME/libs
contains all default jar
libraries).
If I download Sun's JDK bundle and installs it in Linux, it is the same procedure.
However, I need to use Kubuntu's default OpenJDK package. The problem is that all executables are placed in /usr/bin
. But the jars are placed in /usr/share/java
. Since they are not under the same JAVA_HOME
folder I'm having trouble with Grails and maybe there will be trouble with other applications that expect the standard Java structure.
If I use:
JAVA_HOME=/usr
All applications and scripts that want to use any Java executable can use the standard procedure
call $JAVA_HOME/bin/executable
. However, since the jars are in a different place, they are not always found (example: in grails I'm gettingClassDefNotFound
fornative2ascii
).On the other hand, if I use:
JAVA_HOME=/usr/share/java
None of the Java executables (
java
,javac
, etc.) can be found.
So, what is the correct way of handling the JAVA_HOME
variable in a Debian-based Linux?
Thanks for your help,
Luis
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(15)
最终对我有用的东西(Grails 现在工作顺利)几乎就像 Steve B. 指出的那样:
这样,如果用户更改系统的默认 JDK,
JAVA_HOME
仍然可以工作。default-java
是当前 JVM 的符号链接。What finally worked for me (Grails now works smoothly) is doing almost like Steve B. has pointed out:
This way if the user changes the default JDK for the system,
JAVA_HOME
still works.default-java
is a symlink to the current JVM.如果您使用替代方法来管理多个 java 版本,则可以基于符号链接的 java(或 javac)设置
JAVA_HOME
,如下所示:If you use alternatives to manage multiple java versions, you can set the
JAVA_HOME
based on the symlinked java (or javac) like this:标准 Ubuntu 安装似乎将各种 Java 版本放在
/usr/lib/jvm
中。 您在路径中找到的javac
, java 将软链接到此。只要您设置
JAVA_HOME
环境变量并确保您的路径上有新的 Javabin
,在任何您喜欢的地方安装您自己的 Java 版本都没有问题。一个简单的方法是让 Java 主目录作为软链接存在,这样如果您想升级或切换版本,您只需更改它指向的目录 - 例如:
The standard Ubuntu install seems to put the various Java versions in
/usr/lib/jvm
. Thejavac
, java you find in your path will softlink to this.There's no issue with installing your own Java version anywhere you like, as long as you set the
JAVA_HOME
environment variable and make sure to have the new Javabin
on your path.A simple way to do this is to have the Java home exist as a softlink, so that if you want to upgrade or switch versions you only have to change the directory that this points to - e.g.:
我修改了上面的解决方案之一,无论 java 安装在哪里,只要它在您的 PATH 中,这似乎都有效。
I modified one of the solution above and this seems to work no matter where java is installed, as long it's in your PATH.
我通常没有任何 JAVA_HOME 环境变量。 Java可以自己设置。 java内部的java.home系统属性应该是可用的。
I usually don't have any JAVA_HOME environment variable. Java can set it up itself. Inside java java.home system property should be available.
也尝试设置 JAVA_LIB 变量。
Try setting the JAVA_LIB variable also.
如果您遇到找不到 JAR 文件的问题,我还会确保您的 CLASSPATH 设置为包含这些文件的位置。 然而,我确实发现 CLASSPATH 通常需要针对不同的程序进行不同的设置,并且通常最终会为各个程序进行独特的设置。
If you have issues with JAR files not being found I would also ensure your CLASSPATH is set to include the location of those files. I do find however that the CLASSPATH often needs to be set differently for different programs and often ends up being something to set uniquely for individual programs.
更新的答案可以解决您的问题,并且还可以在此处找到在 Ubuntu 上安装 Oracle Java 7 的一般良好方法:http://www.wikihow.com/Install-Oracle-Java-on-Ubuntu-Linux
Updated answer that will solve your problem and also just a general good how-to for installing Oracle Java 7 on Ubuntu can be found here: http://www.wikihow.com/Install-Oracle-Java-on-Ubuntu-Linux
我在 Ubuntu 中的 openjdk-6-jre 和 openjdk-6-jre-headless 软件包中发现了类似的问题。
通过清除 openjdk-6-jre 和 openjdk-6-jre-headless 软件包并重新安装,我的问题得到了解决。 仅在全新安装 openjdk-6-jre 和 openjdk-6-jre-headless 软件包时更新替代方案。
下面是清除后安装的示例:
您可以在上面看到运行
update-alternatives
来设置各种 Java 二进制文件的链接。安装完成后,
/usr/bin
中还有链接、/etc/alternatives
中的链接以及/var/lib/dpkg 中每个二进制文件的文件/替代方案
。让我们将其与不清除的安装进行比较。
如您所见,
update-alternatives
未触发。安装完成后,
/var/lib/dpkg/alternatives
中没有 Java 二进制文件的文件,/etc/alternatives
中没有链接,中也没有链接>/usr/bin
。删除
/var/lib/dpkg/alternatives
中的文件也会破坏update-java-alternatives
。I've discovered similar problems with the openjdk-6-jre and openjdk-6-jre-headless packages in Ubuntu.
My problem was solved by purging the openjdk-6-jre and openjdk-6-jre-headless packages and re-installing. The alternatives are only updated on a fresh install of the openjdk-6-jre and openjdk-6-jre-headless packages.
Below is a sample of installing after purging:
You can see above that
update-alternatives
is run to set up links for the various Java binaries.After this install, there are also links in
/usr/bin
, links in/etc/alternatives
, and files for each binary in/var/lib/dpkg/alternatives
.Let's contast this with installing without purging.
As you see,
update-alternatives
is not triggered.After this install, there are no files for the Java binaries in
/var/lib/dpkg/alternatives
, no links in/etc/alternatives
, and no links in/usr/bin
.The removal of the files in
/var/lib/dpkg/alternatives
also breaksupdate-java-alternatives
.作为 fedora 用户的更新,替代方案将当前 java 目录设置为
/usr/java/default
所以你必须将你的 JAVA_HOME 设置为 /usr/java/default 以便在你的类路径
HTH 中始终有替代当前选择!
As an update for fedora user , alternatives set current java directory to
/usr/java/default
so you have to set your JAVA_HOME to /usr/java/default to always have alternatives curent selection in your classpath
HTH !
我总是倾向于根据
/usr/bin/java
设置 JAVA_HOME。这样,两个选项都指向同一位置
I always tend to set the JAVA_HOME according to the
/usr/bin/java
.This way, both alternatives point to the same location
据我记得,我使用了 update-java-alternatives 脚本而不是 update-alternatives。 它确实为我正确设置了 JAVA_HOME 。
As far as I remember, I used the update-java-alternatives script instead of the update-alternatives. And it did set the JAVA_HOME for me correctly.
请看看 update-alternatives 命令的作用(它有一个很好的人......)。
很快 - 当你有 java-sun-1.4 和 java-opensouce-1.0 时会发生什么......哪一个采用“java”? debian“/usr/bin/java”是符号链接,“/usr/bin/java-sun-1.4”是“/usr/bin/java”的替代品
编辑:
正如理查德所说,
update-alternatives
还不够。 您实际上需要使用update-java-alternatives
。 更多信息请访问:https://help.ubuntu.com/community/Java
Please see what the update-alternatives command does (it has a nice man...).
Shortly - what happens when you have java-sun-1.4 and java-opensouce-1.0 ... which one takes "java"? It debian "/usr/bin/java" is symbolic link and "/usr/bin/java-sun-1.4" is an alternative to "/usr/bin/java"
Edit:
As Richard said,
update-alternatives
is not enough. You actually need to useupdate-java-alternatives
. More info at:https://help.ubuntu.com/community/Java
Ubuntu 12.04 这有效...
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-i386/jre
Ubuntu 12.04 this works...
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-i386/jre
我的正确目标始终是从 Sun 下载并安装它。 然后你就知道所有东西都在哪个目录中。
但是如果你更愿意坚持 Debian 安装它的奇怪方式,我最好的猜测是 java 和 javac 二进制文件所在的父目录。
(因为当您在路径中指定它时,它是 $JAVA_HOME/bin )
(所以在你的情况下它将是... $JAVA_HOME/share 和 $JAVA_HOME 将是 /usr ?)
呃,这听起来不对...
我也有兴趣听到这个问题的答案!
My correct target has always been to download it from Sun and just install it that way. Then you know exactly what directory everything goes in.
But if you'd prefer to stick with the odd way that Debian installs it, my best guess would be the parent directory just above where the java and javac binaries are located.
(since when you specify it in your path it's $JAVA_HOME/bin)
(So in your case it would be ... $JAVA_HOME/share and $JAVA_HOME would be /usr ?)
Eh, that doesn't sound right...
I'm interested to hear the answer to this too!