1java(1) General Commands Manual java(1)
2
6 java - the Java application launcher
7
9 java [ options ] class [ argument ... ]
10 java [ options ] -jar file.jar [ argument ... ]
11 options
14 Command-line options.
15 class
17 Name of the class to be invoked.
18 file.jar
20 Name of the jar file to be invoked. Used only with -jar.
21 argument
23 Argument passed to the main function.
24
27 The java tool launches a Java application. It does this by starting a
28 Java runtime environment, loading a specified class, and invoking that
29 class's main method.
30 The method must be declared public and static, it must not return any
32 value, and it must accept a String array as a parameter. The method
33 declaration must look like the following:
34 public static void main(String args[])
36 By default, the first non-option argument is the name of the class to
39 be invoked. A fully-qualified class name should be used. If the -jar
40 option is specified, the first non-option argument is the name of a JAR
41 archive containing class and resource files for the application, with
42 the startup class indicated by the Main-Class manifest header.
43 The Java runtime searches for the startup class, and other classes
45 used, in three sets of locations: the bootstrap class path, the
46 installed extensions, and the user class path.
47 Non-option arguments after the class name or JAR file name are passed
49 to the main function.
50
52 The launcher has a set of standard options that are supported on the
53 current runtime environment and will be supported in future releases.
54 In addition, the current implementations of the virtual machines sup‐
55 port a set of non-standard options that are subject to change in future
56 releases.
57
59 -client
60 Select the Java HotSpot Client VM. A 64-bit capable jdk currently
62 ignores this option and instead uses the Java Hotspot Server VM.
63 For default VM selection, see Server-Class Machine Detection
65 -server
67 Select the Java HotSpot Server VM. On a 64-bit capable jdk only the
69 Java Hotspot Server VM is supported so the -server option is
70 implicit.
71 For default VM selection, see Server-Class Machine Detection
73 -agentlib:libname[=options]
75 Load native agent library libname, e.g.
76 -agentlib:hprof
78 -agentlib:jdwp=help
80 -agentlib:hprof=help
82 For more information, see JVMTI Agent Command Line Options.
84 -agentpath:pathname[=options]
86 Load a native agent library by full pathname. For more informa‐
87 tion, see JVMTI Agent Command Line Options.
88 -classpath classpath
90 -cp classpath
92 Specify a list of directories, JAR archives, and ZIP archives to
93 search for class files. Class path entries are separated by
94 colons (:). Specifying -classpath or -cp overrides any setting of
95 the CLASSPATH environment variable.
96 If -classpath and -cp are not used and CLASSPATH is not set, the
98 user class path consists of the current directory (.).
99 As a special convenience, a class path element containing a basename
101 of * is considered equivalent to specifying a list of all the files
102 in the directory with the extension .jar or .JAR (a java program
103 cannot tell the difference between the two invocations).
104 For example, if directory foo contains a.jar and b.JAR, then the
105 class path element foo/* is expanded to a A.jar:b.JAR, except that
106 the order of jar files is unspecified. All jar files in the speci‐
107 fied directory, even hidden ones, are included in the list. A class‐
108 path entry consisting simply of * expands to a list of all the jar
109 files in the current directory. The CLASSPATH environment variable,
110 where defined, will be similarly expanded. Any classpath wildcard
111 expansion occurs before the Java virtual machine is started -- no
112 Java program will ever see unexpanded wildcards except by querying
113 the environment. For example; by invoking System.getenv("CLASS‐
114 PATH").
115 For more information on class paths, see Setting the Class Path.
117 -Dproperty=value
119 Set a system property value.
120 -d32
122 -d64
124 Request that the program to be run in a 32-bit or 64-bit environ‐
125 ment, respectively. If the requested environment is not installed
126 or is not supported, an error is reported.
127 Currently only the Java HotSpot Server VM supports 64-bit operation,
129 and the "-server" option is implicit with the use of -d64. And the
130 "-client" option is ignored with the use of -d64. This is subject to
131 change in a future release.
132 If neither -d32 nor -d64 is specified, the default is to run in a
134 32-bit environment, except for 64-bit only systems. This is subject
135 to change in a future release.
136 -enableassertions[:<package name>"..." | :<class name> ]
138 -ea[:<package name>"..." | :<class name> ]
140 Enable assertions. Assertions are disabled by default.
141 With no arguments, enableassertions or -ea enables assertions. With
143 one argument ending in "...", the switch enables assertions in the
144 specified package and any subpackages. If the argument is simply
145 "...", the switch enables assertions in the unnamed package in the
146 current working directory. With one argument not ending in "...",
147 the switch enables assertions in the specified class.
148 If a single command line contains multiple instances of these
150 switches, they are processed in order before loading any classes.
151 So, for example, to run a program with assertions enabled only in
152 package com.wombat.fruitbat (and any subpackages), the following
153 command could be used:
154 java -ea:com.wombat.fruitbat... <Main Class>
155 The -enableassertions and -ea switches apply to all class loaders
157 and to system classes (which do not have a class loader). There is
158 one exception to this rule: in their no-argument form, the switches
159 do not apply to system. This makes it easy to turn on asserts in all
160 classes except for system classes. A separate switch is provided to
161 enable asserts in all system classes; see -enablesystemassertions
162 below.
163 -disableassertions[:<package name>"..." | :<class name> ]
165 -da[:<package name>"..." | :<class name> ]
167 Disable assertions. This is the default.
168 With no arguments, disableassertions or -da disables assertions.
170 With one argument ending in "...", the switch disables assertions in
171 the specified package and any subpackages. If the argument is simply
172 "...", the switch disables assertions in the unnamed package in the
173 current working directory. With one argument not ending in "...",
174 the switch disables assertions in the specified class.
175 To run a program with assertions enabled in package com.wom‐
177 bat.fruitbat but disabled in class com.wombat.fruitbat.Brickbat, the
178 following command could be used:
179 java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat <Main Class>
180 The -disableassertions and -da switches apply to all class loaders
182 and to system classes (which do not have a class loader). There is
183 one exception to this rule: in their no-argument form, the switches
184 do not apply to system. This makes it easy to turn on asserts in all
185 classes except for system classes. A separate switch is provided to
186 enable asserts in all system classes; see -disablesystemassertions
187 below.
188 -enablesystemassertions
190 -esa
192 Enable asserts in all system classes (sets the default assertion
193 status for system classes to true).
194 -disablesystemassertions
196 -dsa
198 Disables asserts in all system classes.
199 -jar
201 Execute a program encapsulated in a JAR file. The first argument
202 is the name of a JAR file instead of a startup class name. In
203 order for this option to work, the manifest of the JAR file must
204 contain a line of the form Main-Class: classname. Here, classname
205 identifies the class having the pub‐
206 lic static void main(String[] args) method that serves as your
207 application's starting point. See the Jar tool reference page and
208 the Jar trail of the Java Tutorial @
209 http://java.sun.com/docs/books/tutorial/jar for information about
210 working with Jar files and Jar-file manifests.
211 When you use this option, the JAR file is the source of all user
213 classes, and other user class path settings are ignored.
214 Note that JAR files that can be run with the "java -jar" option can
216 have their execute permissions set so they can be run without using
217 "java -jar". Refer to Java Archive (JAR) Files.
218 -javaagent:jarpath[=options]
220 Load a Java programming language agent, see java.lang.instrument.
221 -verbose
223 -verbose:class
225 Display information about each class loaded.
226 -verbose:gc
228 Report on each garbage collection event.
229 -verbose:jni
231 Report information about use of native methods and other Java
232 Native Interface activity.
233 -version
235 Display version information and exit.
236 -version:release
238 Specifies that the version specified by release is required by
239 the class or jar file specified on the command line. If the ver‐
240 sion of the java command invoked does not meet this specification
241 and an appropriate implementation is found on the system, the
242 appropriate implementation will be used.
243 release not only can specify an exact version, but can also specify
245 a list of versions called a version string. A version string is an
246 ordered list of version ranges separated by spaces. A version range
247 is either a version-id, a version-id followed by a star (*), a ver‐
248 sion-id followed by a plus sign (+) , or two version-ranges combined
249 using an ampersand (&). The star means prefix match, the plus sign
250 means this version or greater, and the ampersand means the logical
251 anding of the two version-ranges. For example:
252 -version:"1.5.0_04 1.5*&1.5.1_02+"
253 The meaning of the above is that the class or jar file requires
254 either version 1.5.0_02, or a version with 1.5 as a version-id pre‐
255 fix and that is not less than 1.5.1_02. The exact syntax and defini‐
256 tion of version strings may be found in Appendix A of the Java Net‐
257 work Launching Protocol & API Specification (JSR-56).
258 For jar files, the usual preference is to specify version require‐
260 ments in the jar file manifest rather than on the command line.
261 See the following NOTES section for important policy information on
263 the use of this option.
264 -showversion
266 Display version information and continue.
267 -?
269 -help
271 Display usage information and exit.
272 -X Display information about non-standard options and exit.
274 Non-Standard Options
277 -Xint
278 Operate in interpreted-only mode. Compilation to native code
279 is disabled, and all bytecodes are executed by the inter‐
280 preter. The performance benefits offered by the Java HotSpot
281 VMs' adaptive compiler will not be present in this mode.
282 -Xbatch
284 Disable background compilation. Normally the VM will compile
285 the method as a background task, running the method in inter‐
286 preter mode until the background compilation is finished. The
287 -Xbatch flag disables background compilation so that compila‐
288 tion of all methods proceeds as a foreground task until com‐
289 pleted.
290 -Xbootclasspath:bootclasspath
292 Specify a colon-separated list of directories, JAR archives,
293 and ZIP archives to search for boot class files. These are
294 used in place of the boot class files included in the Java 2
295 SDK. Note: Applications that use this option for the purpose
296 of overriding a class in rt.jar should not be deployed as
297 doing so would contravene the Java 2 Runtime Environment
298 binary code license.
299 -Xbootclasspath/a:path
301 Specify a colon-separated path of directires, JAR archives,
302 and ZIP archives to append to the default bootstrap class
303 path.
304 -Xbootclasspath/p:path
306 Specify a colon-separated path of directires, JAR archives,
307 and ZIP archives to prepend in front of the default bootstrap
308 class path. Note: Applications that use this option for the
309 purpose of overriding a class in rt.jar should not be deployed
310 as doing so would contravene the Java 2 Runtime Environment
311 binary code license.
312 -Xcheck:jni
314 Perform additional checks for Java Native Interface (JNI)
315 functions. Specifically, the Java Virtual Machine validates
316 the parameters passed to the JNI function as well as the run‐
317 time environment data before processing the JNI request. Any
318 invalid data encountered indicates a problem in the native
319 code, and the Java Virtual Machine will terminate with a fatal
320 error in such cases. Expect a performance degradation when
321 this option is used.
322 -Xfuture
324 Perform strict class-file format checks. For purposes of back‐
325 wards compatibility, the default format checks performed by
326 the Java 2 SDK's virtual machine are no stricter than the
327 checks performed by 1.1.x versions of the JDK software. The
328 -Xfuture flag turns on stricter class-file format checks that
329 enforce closer conformance to the class-file format specifica‐
330 tion. Developers are encouraged to use this flag when develop‐
331 ing new code because the stricter checks will become the
332 default in future releases of the Java application launcher.
333 -Xnoclassgc
335 Disable class garbage collection. Use of this option will pre‐
336 vent memory recovery from loaded classes thus increasing over‐
337 all memory usage. This could cause OutOfMemoryError to be
338 thrown in some applications.
339 -Xincgc
341 Enable the incremental garbage collector. The incremental
342 garbage collector, which is off by default, will reduce the
343 occasional long garbage-collection pauses during program exe‐
344 cution. The incremental garbage collector will at times exe‐
345 cute concurrently with the program and during such times will
346 reduce the processor capacity available to the program.
347 -Xloggc:file
349 Report on each garbage collection event, as with -verbose:gc,
350 but log this data to file. In addition to the information
351 -verbose:gc gives, each reported event will be preceeded by
352 the time (in seconds) since the first garbage-collection
353 event.
354 Always use a local file system for storage of this file to avoid
356 stalling the JVM due to network latency. The file may be trun‐
357 cated in the case of a full file system and logging will continue
358 on the truncated file. This option overrides -verbose:gc if both
359 are given on the command line.
360 -Xmsn
362 Specify the initial size, in bytes, of the memory allocation
363 pool. This value must be a multiple of 1024 greater than 1MB.
364 Append the letter k or K to indicate kilobytes, or m or M to
365 indicate megabytes. The default value is chosen at runtime
366 based on system configuration. For more information, see
367 HotSpot Ergonomics
368 Examples:
369 -Xms6291456
372 -Xms6144k
373 -Xms6m
374 -Xmxn
377 Specify the maximum size, in bytes, of the memory allocation
378 pool. This value must a multiple of 1024 greater than 2MB.
379 Append the letter k or K to indicate kilobytes, or m or M to
380 indicate megabytes. The default value is chosen at runtime
381 based on system configuration. For more information, see
382 HotSpot Ergonomics
383 Examples:
384 -Xmx83886080
387 -Xmx81920k
388 -Xmx80m
389 On Solaris 7 and Solaris 8 SPARC platforms, the upper limit for
391 this value is approximately 4000m minus overhead amounts. On
392 Solaris 2.6 and x86 platforms, the upper limit is approximately
393 2000m minus overhead amounts. On Linux platforms, the upper limit
394 is approximately 2000m minus overhead amounts.
395 -Xprof
397 Profiles the running program, and sends profiling data to
398 standard output. This option is provided as a utility that is
399 useful in program development and is not intended to be be
400 used in production systems.
401 -Xrs
403 Reduces use of operating-system signals by the Java virtual
404 machine (JVM).
405 In a previous release, the Shutdown Hooks facility was added to
407 allow orderly shutdown of a Java application. The intent was to
408 allow user cleanup code (such as closing database connections) to
409 run at shutdown, even if the JVM terminates abruptly.
410 Sun's JVM catches signals to implement shutdown hooks for abnor‐
412 mal JVM termination. The JVM uses SIGHUP, SIGINT, and SIGTERM to
413 initiate the running of shutdown hooks.
414 The JVM uses a similar mechanism to implement the pre-1.2 feature
416 of dumping thread stacks for debugging purposes. Sun's JVM uses
417 SIGQUIT to perform thread dumps.
418 Applications embedding the JVM frequently need to trap signals
420 like SIGINT or SIGTERM, which can lead to interference with the
421 JVM's own signal handlers. The -Xrs command-line option is avail‐
422 able to address this issue. When -Xrs is used on Sun's JVM, the
423 signal masks for SIGINT, SIGTERM, SIGHUP, and SIGQUIT are not
424 changed by the JVM, and signal handlers for these signals are not
425 installed.
426 There are two consequences of specifying -Xrs:
428 o SIGQUIT thread dumps are not available.
430 o User code is responsible for causing shutdown hooks to run,
432 for example by calling System.exit() when the JVM is to be
433 terminated.
434 -Xssn
436 Set thread stack size.
437 -XX:+UseAltSigs
439 The VM uses SIGUSR1 and SIGUSR2 by default, which can some‐
440 times conflict with applications that signal-chain SIGUSR1 and
441 SIGUSR2. The -XX:+UseAltSigs option will cause the VM to use
442 signals other than SIGUSR1 and SIGUSR2 as the default.
443
446 The -version:release command line option places no restrictions on the
447 complexity of the release specification. However, only a restricted
448 subset of the possible release specifications represent sound policy
449 and only these are fully supported. These policies are:
450 1. Any version, represented by not using this option.
452 2. Any version greater than an arbitrarily precise version-id. For
454 example:
455 "1.5.0_03+"
456 Would utilize any version greater than 1.5.0_03. This is useful for
458 a case where an interface was introduced (or a bug fixed) in the
459 release specified.
460 3. A version greater than an arbitrarily precise version-id, bounded
462 by the upper bound of that release family. For example:
463 "1.5.0_03+&1.5*"
464 4. "Or" expressions of items 2. or 3. above. For example:
466 "1.4.2_05+&1.4* 1.5+"
467 Similar to item 2. this is useful when a change was introduced in
468 a release (1.5) but also made available in updates to previous
469 releases.
470
473 o javac - the Java programming language compiler
474 o jdb - Java Application Debugger
476 o javah - C Header and Stub File Generator
478 o jar - JAR Archive Tool
480 o The Java Extensions Framework
482 o Security Features.
484 o HotSpot VM Specific Options @
486 http://java.sun.com/docs/hotspot/VMOptions.html.
487 07 Aug 2006 java(1)