![FreeBSD/TrueOS软件包javavm中的命令javavmwrapper](https://linux22.com/image/126195/FreeBSD%2FTrueOS%E8%BD%AF%E4%BB%B6%E5%8C%85javavm%E4%B8%AD%E7%9A%84%E5%91%BD%E4%BB%A4javavmwrapper.png)
设置环境变量可以代替使用update-alternatives
吗?
如果不是的话,我们什么时候该用哪种方式呢?谢谢。
我的问题来自阅读https://askubuntu.com/a/895024/1471
大多数答案对我来说太复杂了。
最初,Oracle 根据设置一些环境变量决定能够安装多个版本的 Java。
这很简单,但对于那些不知道这些变量的人来说太复杂了,有人发明了“update-java-alternatives”。
“update-java-alternatives”已被证明很简单,当一切都为您配置好后,您只需执行该程序,然后选择您想要的版本即可。
问题是这个解决方案太复杂而无法配置,如果你必须自己配置(你必须为java的每个命令配置它)。
最好的答案是回到基础。
.bash_profile
在您的(对于您的用户)或(对于每个用户)中设置/etc/profile
以下变量:JAVA_HOME=<The home of your new java distribution> PATH=<The bin directory of your new java distribution>:$PATH
就我而言,这甚至更容易......我已经有一个包含
/etc/profile.d
以下内容的文件(刚刚将其更新为新的目录结构):export J2SDKDIR=/usr/lib/jvm/jdk1.8.0_121 export J2REDIR=/usr/lib/jvm/jdk1.8.0_121/jre export PATH=/usr/lib/jvm/jdk1.8.0_121/bin:/usr/lib/jvm/jdk1.8.0_121/db/bin:/usr/lib/jvm/jdk1.8.0_121/jre/bin:$PATH export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_121 export DERBY_HOME=/usr/lib/jvm/jdk1.8.0_121/db
就这样!!!
答案1
是的;有些系统确实就是这样做的。
FreeBSD/TrueOS软件包javavm
中的命令javavmwrapper
在 FreeBSD/TrueOS 上,JRE 中提供的所有命令都是/usr/local/bin/
来自这些名称的符号链接 ( appletviewer
, checkvms
, extcheck
, idlj
, jar
, jarsigner
, java
, java-rmi.cgi
, javac
, javadoc
, javah
, javap
, jcmd
, jconsole
, jdb
, jdeps
, jhat
, jinfo
, jjs
, jmap
, jps
, jrunscript
, jsadebugd
, jstack
, jstat
, jstatd
, keytool
, manvm
, native2ascii
, orbd
,pack200
,policytool
,registervm
,rmic
,rmid
,rmiregistry
,schemagen
,serialver
,,servertool
,tnameserv
,unpack200
,unregistervm
,wsgen
,wsimport
并xjc
。/usr/local/bin/javavm
该列表的长度,以及人们通常希望所有这些命令都使用相同 JVM 的事实,就是 Debian/Ubuntu 拥有update-java-alternatives
.稍微简化一下:update-java-alternatives
是一个知道所有这些名称并调用update-alternatives
所有这些名称的程序。 (在 Debian/Ubuntu 系统中,通过使用update-alternatives
设置单个命令而不是使用update-java-alternatives
一次性设置所有命令,可以让不同的命令调用不同的 JRE 。这对于 FreeBSD/TrueOS 的javavmwrapper
机制来说是不可能的。)
FreeBSD/TrueOSjavavmwrapper
包的方法只是简单地包含所有可能的命令名称,并且不会在 JRE 之间进行更改时移动符号链接,而是采用一个包装程序,在运行时以编程方式而不是结果做出决定文件系统中的符号链接。
/usr/local/bin/javavm
是那个包装程序。它
- 确定它被调用的名称(第 0 个参数的基本名称);
- 扫描
/usr/local/etc/javavms
文件以查找合适的 JRE 的根目录名称(与用户选择的操作系统、供应商以及在 、 和环境变量中设置的版本相JAVA_OS
匹配JAVA_VENDOR
)JAVA_VERSION
; - 设置
JAVA_HOME
为该根目录名称的值;和 ${JAVA_HOME}/bin/${basename}
与其中之一或${JAVA_HOME}/jre/bin/${basename}
取决于从中找到的内容覆盖自身。
与 nosh 工具集的服务捆绑包
当创建使用 nosh 工具集的服务捆绑run
程序时,任何人都可以依赖这样一个事实:系统管理员提供了一个“通用”java
命令来选择正确的 JRE,使用 Debian/Ubuntualternatives
系统等系统或使用 FreeBSD/TrueOS 等系统javavmwrapper
系统 …
#!/bin/nosh #基于 HBase 编写的分布式、可扩展的时间序列数据库 机器环境 envdir 环境 硬限制-o 65536 软限制 -o 硬 setuidgid——opentsdb sh -c "exec java ${JAVA_OPTS} -Xmx6000 -classpath \"${CLASSPATH}:${HBASE_CONF}\" -enableassertions -enablesystemassertions ${BIGTABLE_SUPPORT} -DLOG_FILE_PREFIX=/var/log/opentsdb/\"${MACHINEID }\"-net.opentsdb.tools.TSDMain"
...或者可以使用工具集的find-matching-jvm
工具。
#!/bin/nosh #基于 HBase 编写的分布式、可扩展的时间序列数据库 机器环境 envdir 环境 硬限制-o 65536 软限制 -o 硬 查找匹配jvm --版本 1.6 --版本 1.7 --版本 1.8 setuidgid——opentsdb sh -c "exec \"${JAVA_HOME}/bin/java\" ${JAVA_OPTS} -Xmx6000 -classpath \"${CLASSPATH}:${HBASE_CONF}\" -enableassertions -enablesystemassertions ${BIGTABLE_SUPPORT} -DLOG_FILE_PREFIX=/ var/log/opentsdb/\"${MACHINEID}\"- net.opentsdb.tools.TSDMain"
find-matching-jvm
执行一部分工作javavm
,并选择由命令行选项而不是环境变量驱动的 JRE;并且它还知道更多 JVM 配置信息的来源。它
- 查找合适的 JRE 的根目录名称(与用户选择的操作系统、供应商和命令行选项设置的版本相匹配),扫描文件(
/usr/local/etc/javavms
如果存在),/usr/lib/jvm
如果不存在则扫描目录,并硬连线搜索路径,如果没有的话; - 设置
JAVA_HOME
为该根目录名称的值;和 - 链加载到下一个程序,指定为其命令行参数的其余部分。
在示例中,下一个程序(实际上是下一个程序,只是一个)是 shell,它被告知用"${JAVA_HOME}/bin/java"
.
基础知识
这里的基本原理是,要么使用文件系统和一组符号链接来编码从通用命令映射到/usr/bin/java
所需的特定 JRE 的决策,要么提供一个通过扫描配置信息以编程方式查找所需 JRE 的命令。 Debian/Ubuntu 的替代系统执行前者。 FreeBSD/TrueOS 的包装系统执行后者。
但这里有一个范围,如 nosh 服务捆绑run
程序示例所示。
环境JAVA_HOME
变量是可以用作中介的约定。 (注意,Java VM 和语言本身不需要此环境变量。)可以找到 JRE,将其根目录放在JAVA_HOME
环境变量中,并使用始终直接调用的约定。${JAVA_HOME}/bin/somecommand
这当然是设置环境的人所.profile
采用的惯例。 Xe 设置JAVA_HOME
为 xyr 选择,并期望将所有内容调用为 的约定 ,xe 通过添加(相当于)到 xyr shell 的命令搜索路径来实现。 ${JAVA_HOME}/bin/somecommand
${JAVA_HOME}/bin/
正如所描述的, FreeBSD/TrueOSjavavm
包装器和 nosh 工具集的find-matching-jvm
工具本身都使用此约定,并且如果它们发现它已经在使用,则尊重它。如果他们发现JAVA_HOME
环境变量已经设置,他们只会跳过所有步骤,包括他们自己设置的点。
Debian/Ubuntu 替代系统则不然。使符号链接了解环境变量有些困难,并且替代系统将已经做出的决策(在系统管理员update-alternatives
作为 的一部分显式或间接运行时做出的update-java-alternatives
)编码到 中的符号链接中/etc/alternatives/
。
这就是为什么重要的是还在 Debian/Ubuntu 上设置PATH
为包含(相当于) 。${JAVA_HOME}/bin/
如果不这样做,调用java
will find/usr/bin/java
将搜索替代系统的符号链接以查找预选的 JRE。只有显式添加到shell的命令搜索路径中才会${JAVA_HOME}/bin/
直接找到。
进一步阅读
javavm
。 用户手册。免费的BSD。 2005年。javavmwrapper
。 FreeBSD 端口。- 乔纳森·德博因·波拉德 (2017)。
find-matching-jvm
。 小吃指南。软件。
答案2
在选择要运行的程序时,环境变量和环境变量update-alternatives
是互补的。前者允许任何人定义设置的值,无论所使用的软件都支持;后者允许任何人定义设置的值。后者允许系统管理员为常用命令选择默认提供程序。
例如,管理员可以选择系统默认值编辑器和寻呼机分别配置editor
和pager
替代方案;用户可以通过分别设置EDITOR
(或VISUAL
) 和PAGER
环境变量来选择他们喜欢的编辑器和分页器。
因此,环境变量不会取代update-alternatives
,它们适用于不同的用例。然而,他们可以覆盖由 设定的选择update-alternatives
。