java_home(1) General Commands Manual java_home(1)NAME
java_home - return a value for $JAVA_HOME
The java_home command returns a path suitable for setting the JAVA_HOME environment variable. It determines this path from the user's
enabled and preferred JVMs in the Java Preferences application. Additional constraints may be provided to filter the list of JVMs avail-
able. By default, if no constraints match the available list of JVMs, the default order is used. The path is printed to standard output.
OPTIONS -v or --version version
Filters the returned JVMs by the major platform version in "JVMVersion" form. Example versions: "1.5+", or "1.6*".
-a or --arch architecture
Filters the returned JVMs by the architecture they support. Example architectures: "i386", "x86_64", or "ppc".
-d or --datamodel datamodel
Filters the returned JVMs capable of running in 32 or 64-bit mode. Supported datamodels: "-d32" and "-d64". Specifying a datamodel
is synonymous with specifying a particular architecture.
-t or --task task
Selects from the list of JVMs which can run a specific task. The order of each of these lists is set by the Java Preferences appli-
cation. Supported tasks: "Applets", "WebStart", "BundledApp", "JNI" and "CommandLine". The default task is "CommandLine".
-F or --failfast
Immediately fails when filters return no JVMs; does not print out the path to the default $JAVA_HOME.
--exec command ...
Executes the command at $JAVA_HOME/bin/<command> and passes the remaining arguments. Any arguments to select which $JAVA_HOME to use
must precede the --exec option.
-X or --xml
Prints the list of selected JVMs and associated properties as an XML plist to stdout.
-V or --verbose
Prints the matching list of JVMs and architectures to stderr.
-h or --help
Brief usage information.
/usr/libexec/java_home helps users set a $JAVA_HOME in their login rc files, or provides a way for command-line Java tools to use the most
appropriate JVM which can satisfy a minimum version or architecture requirement. The --exec argument can invoke tools in the selected
$JAVA_HOME/bin directory, which is useful for starting Java command-line tools from launchd plists without hardcoding the full path to the
Java command-line tool.
Usage for bash-style shells:
$ export JAVA_HOME=`/usr/libexec/java_home`
Usage for csh-style shells:
% setenv JAVA_HOME `/usr/libexec/java_home`
04 August 2010 java_home(1)
Check Out this Related Man Page
JAVA-WRAPPERS(7) Java wrappers JAVA-WRAPPERS(7)NAME
java-wrappers - capacities shared by java wrapper scripts
Most Java programs are not run directly, but through small shell scripts that take care of various things, such as finding a suitable java
environment and looking for libraries.
To ease the task of the maintainers, they rely on a library providing runtime detection, library detection and other features. This manual
page describes the common features of all those scripts, and to which point you can configure them. This is mainly done via environment
java-wrappers understands some environment variables:
The java command that will be run. If this variable is set, it disables all lookup for a java runtime.
Specifies a directory that will be looked for a java or a jdb executable (depending on the setting of JAVA_DEBUGGER). It has prece-
dence over JAVA_HOME but not over JAVA_CMD.
A path to a java runtime. If this variable is set, all lookup for a java runtime is disabled, except that if no java executable is
found in the path, the command java is used.
A probably more easy-to-use version of the JAVA_HOME variable: instead of specifying the full path of the java runtime, you name it.
List of available flavors can be found in the file /usr/lib/java-wrappers/jvm-list.sh. See examples below.
If this is set, the wrapper will try to pick up a java debugger rather than a java interpreter. This will fail if the jbd of the
runtime found is a stub.
Additional classpath, will have priority over the one found by the wrapper.
Additional arguments to the java command. They will come before all other arguments.
If this variable is set, it will be the only classpath. You'd better know what you are doing.
This is probably the most important variable; if it set, the wrapper will print out useful information as it goes by its business,
such as which runtime it did find, and which command is run eventually.
The path where the wrappers will go looking for jar archives. If not set, the wrapper will look into the default directory,
/usr/share/java. Warning : the wrapper will not look anywhere else than in JAVA_JARPATH. Setting it incorrectly will most probably
result in early crashes.
The examples all rely on rasterizer(1), from the package libbatik-java, but they really apply to all scripts that use java-wrappers.
Print out debugging information:
Limit rasterizer's memory to 80 MB:
Force rasterizer to run with kaffe(1):
The same, but using JAVA_BINDIR:
Force rasterizer to run with openjdk:
Debug rasterizer with Sun's debugger, while printing debugging information from the wrapper:
DEBUG_WRAPPER=1 JAVA_CMD=/usr/lib/jvm/java-6-sun/bin/jdb rasterizer
Care has been taken to make the wrappers bug-free. If that was not the case, please file a bug report against the java-wrappers package.
If you wish to submit any problem with a java executable relying on java-wrappers, please also submit the output of the command run with
DEBUG_WRAPPER=1. It will save one mail exchange and therefore potentially reduce the time it takes to fix the bug.
There is currently no documentation about writing a wrapper script save the comments in /usr/lib/java-wrappers/java-wrappers.sh. If you
have to write one, we suggest you base yourself upon, for instance, the rasterizer wrapper script, or any other one (just pick up any
direct reverse dependency of java-wrappers and look for scripts).
SEE ALSO java(1), jdb(1)
java-wrappers and its documentation were written by Vincent Fourmond <email@example.com>
Version 0.1.16 2010-05-04 JAVA-WRAPPERS(7)