The java tool launches a Java application. It does this by
starting a Java runtime environment, loading a
specified class, and invoking that class's main method. The
method declaration must look like the following:
public static void main(String args[])
The method must be declared public and static, it must not
return any value, and it must accept a String array as a
parameter. By default, the first non-option argument is the name
of the class to be invoked. A fully-qualified class name should be used.
If the -jar option is specified, the first non-option argument
is the name of a JAR archive containing class and resource files
for the application, with the startup class indicated by the
Main-Class manifest header.
The Java runtime searches for the startup class, and other classes
used, in three sets of locations: the bootstrap class path, the
installed extensions, and the user class path.
Non-option arguments after the class name or JAR file name are passed
to the main function.
The javaw command is identical to java, except that with
javaw there is no associated console window. Use javaw when
you don't want a command prompt window to appear.
These are the differences between java and oldjava
The oldjava launcher does not support the extension
mechanism. Extension packages can still be used as class and
resource archives.
The oldjava launcher uses the bootstrap class loader for
all classes, while the java launcher uses the bootstrap
class loader only for bootstrap classes. This allows programming
techniques that are incompatible with the base class loader.
With java, the -classpath and -cp
options specify a search path for user classes, and cannot be used
to specify locations for bootstrap classes. With oldjava the
-classpath and -cp options specify locations for
all classes, including botstrap classes.
Note that java and oldjava do not differ in
their use of the CLASSPATH environment variable. Unless
overridden by -classpath or -cp, CLASSPATH
always specifies the location of user classes, but says nothing
about the bootstrap classes.
The oldjava launcher supports all the 1.2 security
features. With oldjava, however, classes loaded from the
class path will not have a protection domain and will therefore
have all permissions which is true only for bootstrap classes with
the java launcher.
This command using oldjava
oldjava -classpath <path> ...
is equivalent to this command using java
java -Xbootclasspath:<path> -Djava.ext.dirs= ...
where in both cases <path> contains
the file rt.jar. (See the JDK File
Structure document for a description of rt.jar and its
location in the JDK software.)
The default behavior of the launcher is to execute bytecodes using a
Just-in-Time compiler, or JIT. The default compiler is located at
jre\bin\symcjit.dll. When a class is loaded, the JIT
translates the class bytecodes into native machine code. Using a JIT
causes a slight delay after each class load, but can improve overall
program performance. In some cases, execution time will improve by a factor
of ten.
If the JIT is disabled, bytecodes are executed directly by an
interpreter. There are two ways to disable the JIT:
Set the environment variable JAVA_COMPILER to NONE,
using the set command.
C:\> set JAVA_COMPILER=NONE
On Windows NT, you can also use the System Control Panel to set
JAVA_COMPILER.
Use the -D command-line option to set java.compiler to
NONE.
C:\> java -Djava.compiler=NONE myapp
Using the command-line option overrides the setting of the
JAVA_COMPILER environment variable.
You can also use JAVA_COMPILER or java.compiler to the
specify that an alternative JIT should be used:
C:\> set JAVA_COMPILER=foo
or
C:\> java -Djava.compiler=foo myapp
The .dll filename
extension is added to "foo", so that, in this example, the virtual machine will
search for a JIT compiler named foo.dll. The search for
the alternative compiler is made in the jre\bin directory
and on the system's PATH. If no such compiler is found, the virtual
machine will default to using the interpreter.
The launcher has a set of standard options that are supported on the
current runtime environment and will be supported in future releases.
An additional set of non-standard options are specific to the current
virtual machine implementation and are subject to change in the future.
Non-standard options begin with -X
Specify a list of directories, JAR archives, and ZIP
archives to search for class files. Class path entries are
separated by semicolons (;). Specifying
-classpath or -cp overrides any setting of the
CLASSPATH environment variable.
Used with java or javaw, -classpath or
-cp only specify the class path for user classes. Used
with oldjava or oldjavaw, -classpath or
-cp specify the class path for both user classes and
bootstrap classes.
If -classpath and -cp are not used and
CLASSPATH is not set, the user class path consists of
the current directory (.).
Execute a program encapsulated in a JAR file. The first
argument is the name of a JAR file instead of a startup
class name. In order for this option to work, the manifest of
the JAR file must contain a line of the form
Main-Class: classname.
Here, classname identifies the class having the
public static void main(String[] args)
method that serves as your application's starting point. See
the Jar tool reference page and
the Jar trail of the
Java
Tutorial for information about working with Jar files and
Jar-file manifests.
When you use this option, the
JAR file is the source of all user classes, and other user class
path settings are ignored.
The oldjava and oldjavaw tools do
not support the -jar option.
-verbose
-verbose:class
Display information about each class loaded.
-verbose:gc
Report on each garbage collection event.
-verbose:jni
Report information about use of native methods and other
Java Native Interface activity.
-version
Display version information and exit.
-?
-help
Display usage information and exit.
-X
Display information about non-standard options and exit.
Specify a semicolon-separated list of directories, JAR
archives, and ZIP archives to search for boot class files.
These are used in place of the boot class files included in the
JDK 1.2 software.
-Xdebug
Start with the debugger enabled. The Java interpereter
prints out a password for jdb's use. Refer to
jdb description for more
details and an example.
-Xnoclassgc
Disable class garbage collection
-Xmsn
Specify the initial size of the memory allocation pool.
This value must greather than 1000. To multiply the value by
1000, append the letter k. To multiply the value by 1
million, append the letter m. The default value is
1m
-Xmxn
Specify the maximum size of the memory allocation pool.
This value must greather than 1000. To multiply the value by
1000, append the letter k. To multiply the value by 1
million, append the letter m. The default value is
64m.
-Xrunhprof[:help][:<suboption>=<value>,...]
Enables cpu, heap, or monitor profiling. This option is typically
followed by a list of comma-separated "<suboption>=<value>" pairs.
Run the command java -Xrunhprof:help to obtain a
list of suboptions and their default values.
-Xrs
Reduce the use of operating system signals.
-Xcheck:jni
Perform additional check for Java Native Interface
functions.
-Xfuture
Perform strict class-file format checks. For purposes of backwards
compatibility, the default format checks performed by the
Java 2 SDK's virtual machine are no stricter than
the checks performed by 1.1.x versions of the JDK software. The
-Xfuture flag turns on stricter class-file format checks
that enforce closer conformance to the class-file format
specification. Developers are encouraged to use this flag
when developing new code because the stricter checks will
become the default in future releases of the Java application
launcher.