☰

FreeBSD/TrueOS软件包javavm中的命令javavmwrapper

tag-icon • tag-icon software-installation environment-variables alternatives
FreeBSD/TrueOS软件包javavm中的命令javavmwrapper

设置环境变量可以代替使用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是那个包装程序。它

  1. 确定它被调用的名称（第 0 个参数的基本名称）；
  2. 扫描/usr/local/etc/javavms文件以查找合适的 JRE 的根目录名称（与用户选择的操作系统、供应商以及在 、 和环境变量中设置的版本相JAVA_OS匹配JAVA_VENDOR）JAVA_VERSION；
  3. 设置JAVA_HOME为该根目录名称的值；和
  4. ${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 配置信息的来源。它

  1. 查找合适的 JRE 的根目录名称（与用户选择的操作系统、供应商和命令行选项设置的版本相匹配），扫描文件（/usr/local/etc/javavms如果存在），/usr/lib/jvm如果不存在则扫描目录，并硬连线搜索路径，如果没有的话；
  2. 设置JAVA_HOME为该根目录名称的值；和
  3. 链加载到下一个程序，指定为其命令行参数的其余部分。

在示例中，下一个程序（实际上是下一个程序，只是一个）是 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/如果不这样做，调用javawill find/usr/bin/java将搜索替代系统的符号链接以查找预选的 JRE。只有显式添加到shell的命令搜索路径中才会${JAVA_HOME}/bin/直接找到。

进一步阅读

答案2

在选择要运行的程序时，环境变量和环境变量update-alternatives是互补的。前者允许任何人定义设置的值，无论所使用的软件都支持；后者允许任何人定义设置的值。后者允许系统管理员为常用命令选择默认提供程序。

例如，管理员可以选择系统默认值编辑器和寻呼机分别配置editor和pager替代方案；用户可以通过分别设置EDITOR(或VISUAL) 和PAGER环境变量来选择他们喜欢的编辑器和分页器。

因此，环境变量不会取代update-alternatives，它们适用于不同的用例。然而，他们可以覆盖由 设定的选择update-alternatives。

相关内容