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. See Options.
15 class
17 The name of the class to be called.
18 file.jar
20 The name of the JAR file to be called. Used only with the -jar
21 command.
22 argument
24 The arguments passed to the main function.
25
28 The java command starts a Java application. It does this by starting a
29 Java runtime environment, loading a specified class, and calling that
30 class's main method.
31 The method must be declared public and static, it must not return any
33 value, and it must accept a String array as a parameter. The method
34 declaration has the following form:
35 public static void main(String args[])
37 By default, the first argument without an option is the name of the
40 class to be called. A fully qualified class name should be used. If the
41 -jar option is specified, then the first non-option argument is the
42 name of a JAR file containing class and resource files for the applica‐
43 tion, with the startup class indicated by the Main-Class manifest
44 header.
45 The Java runtime searches for the startup class, and other classes
47 used, in three sets of locations: the bootstrap class path, the
48 installed extensions, and the user class path.
49 Non-option arguments after the class name or JAR file name are passed
51 to the main function.
52
54 The launcher has a set of standard options that are supported in the
55 current runtime environment.
56 In addition, the current implementations of the virtual machines sup‐
58 port a set of nonstandard options that are subject to change in future
59 releases. See Nonstandard Options.
60 Standard Options
62 -client
63 Selects the Java HotSpot Client VM. A 64-bit capable JDK cur‐
64 rently ignores this option and instead uses the Java Hotspot
65 Server VM.
66 For default Java VM selection, see Server-Class Machine Detection
67 at http://docs.oracle.com/javase/7/docs/tech‐
68 notes/guides/vm/server-class.html
69 -server
71 Selects the Java HotSpot Server VM. On a 64-bit capable JDK, only
72 the Java Hotspot Server VM is supported so the -server option is
73 implicit.
74 For default a Java VM selection, see Server-Class Machine Detec‐
75 tion at http://docs.oracle.com/javase/7/docs/tech‐
76 notes/guides/vm/server-class.html
77 -agentlib:libname[=options]
79 Loads native agent library libname, for example:
80 -agentlib:hprof
81 -agentlib:jdwp=help
83 -agentlib:hprof=help
85 See JVMTI Agent Command-Line Options at http://docs.ora‐
86 cle.com/javase/7/docs/platform/jvmti/jvmti.html#starting
87 -agentpath:pathname[=options]
89 Loads a native agent library by full pathname. See JVMTI Com‐
90 mand-Line Options at http://docs.oracle.com/javase/7/docs/plat‐
91 form/jvmti/jvmti.html#starting
92 -classpath classpath, -cp classpath
94 Specifies a list of directories, JAR files, and ZIP archives to
95 search for class files. Separate class path entries with colons
96 (:). Specifying -classpath or -cp overrides any setting of the
97 CLASSPATH environment variable.
98 If -classpath and -cp are not used and CLASSPATH is not set, then
99 the user class path consists of the current directory (.).
100 As a special convenience, a class path element that contains a
101 base name of * is considered equivalent to specifying a list of
102 all the files in the directory with the extension .jar or .JAR. A
103 Java program cannot tell the difference between the two invoca‐
104 tions.
105 For example, if directory mydir contains a.jar and b.JAR, then
106 the class path element mydir/* is expanded to a A.jar:b.JAR,
107 except that the order of jar files is unspecified. All jar files
108 in the specified directory, even hidden ones, are included in the
109 list. A class path entry consisting simply of * expands to a list
110 of all the jar files in the current directory. The CLASSPATH
111 environment variable, where defined, will be similarly expanded.
112 Any class path wildcard expansion occurs before the Java VM is
113 started. No Java program will ever see wild cards that are not
114 expanded except by querying the environment. For example, by
115 calling System.getenv("CLASSPATH").
116 -Dproperty=value
118 Sets a system property value.
119 -d32
121 Run the application in a 32-bit environment. If a 32-bit environ‐
122 ment is not installed or is not supported, an error will be
123 reported. By default, the application is run in a 32-bit environ‐
124 ment unless a 64-bit only system is used.
125 -d64
127 Run the application in a 64-bit environment. If a 64-bit environ‐
128 ment is not installed or is not supported, an error will be
129 reported. By default, the application is run in a 32-bit environ‐
130 ment unless a 64-bit only system is used.
131 Currently only the Java HotSpot Server VM supports 64-bit opera‐
132 tion, and the -server option is implicit with the use of -d64.
133 The -client option is ignored with the use of -d64. This is sub‐
134 ject to change in a future release.
135 -disableassertions[:package name"..." | :class name ], -da[:package
137 name"..." | :class name ]
138 Disable assertions. This is the default.
139 With no arguments, -disableassertions or -da disables assertions.
140 With one argument ending in "...", the switch disables assertions
141 in the specified package and any subpackages. If the argument is
142 "...", then the switch disables assertions in the unnamed package
143 in the current working directory. With one argument not ending in
144 "...", the switch disables assertions in the specified class.
145 To run a program with assertions enabled in package com.wom‐
146 bat.fruitbat but disabled in class com.wombat.fruitbat.Brickbat,
147 the following command could be used:
148 java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat <Main Class>
149 The -disableassertions and -da switches apply to all class load‐
150 ers and to system classes (which do not have a class loader).
151 There is one exception to this rule: in their no-argument form,
152 the switches do not apply to system. This makes it easy to turn
153 on asserts in all classes except for system classes. The -dis‐
154 ablesystemassertions option provides a separate swith to enable
155 assertions in all system classes.
156 -enableassertions[:package name"..." | :class name ], -ea[:package
158 name"..." | :class name ]
159 Enable assertions. Assertions are disabled by default.
160 With no arguments, -enableassertions or -ea enables assertions.
161 With one argument ending in "...", the switch enables assertions
162 in the specified package and any subpackages. If the argument is
163 "...", then the switch enables assertions in the unnamed package
164 in the current working directory. With one argument not ending in
165 "...", the switch enables assertions in the specified class.
166 If a single command contains multiple instances of these
167 switches, then they are processed in order before loading any
168 classes. So, for example, to run a program with assertions
169 enabled only in package com.wombat.fruitbat (and any subpack‐
170 ages), the following command could be used:
171 java -ea:com.wombat.fruitbat... <Main Class>
172 The -enableassertions and -ea switches apply to all class loaders
173 and to system classes (which do not have a class loader). There
174 is one exception to this rule: in their no-argument form, the
175 switches do not apply to system. This makes it easy to turn on
176 asserts in all classes except for system classes. The -enablesys‐
177 temassertions option provides a separate switch to enable asser‐
178 tions in all system classes.
179 -enablesystemassertions, -esa
181 Enable assertions in all system classes (sets the default asser‐
182 tion status for system classes to true).
183 -disablesystemassertions, -dsa
185 Disables assertions in all system classes.
186 -help or -?
188 Displays usage information and exit.
189 -jar
191 Executes a program encapsulated in a JAR file. The first argument
192 is the name of a JAR file instead of a startup class name. For
193 this option to work, the manifest of the JAR file must contain a
194 line in the form Main-Class: classname. Here, classname identi‐
195 fies the class with the public static void main(String[] args)
196 method that serves as your application's starting point.
197 When you use this option, the JAR file is the source of all user
198 classes, and other user class path settings are ignored.
199 JAR files that can be run with the java -jar option can have
200 their execute permissions set so they can be run without using
201 java -jar. See JAR File Overview at http://docs.ora‐
202 cle.com/javase/7/docs/technotes/guides/jar/jarGuide.html
203 -javaagent:jarpath[=options]
205 Loads a Java programming language agent. For more information
206 about instrumenting Java applications, see the java.lang.instru‐
207 ment package description in the Java API documentation at
208 http://docs.oracle.com/javase/7/docs/api/java/lang/instru‐
209 ment/package-summary.html @
210 http://docs.oracle.com/javase/7/docs/api/java/lang/instru‐
211 ment/package-summary.html
212 -jre-restrict-search
214 Includes user-private JREs in the version search.
215 -no-jre-restrict-search
217 Excludes user-private JREs in the version search.
218 -showversion
220 Displays version information and continues.
221 -splash:imagepath
223 Shows splash screen with image specified by imagepath.
224 -verbose, -verbose:class
226 Displays information about each class loaded.
227 -verbose:gc
229 Reports on each garbage collection event.
230 -verbose:jni
232 Reports information about use of native methods and other Java
233 Native Interface activity.
234 -version
236 Displays version information and exits. See also the -showversion
237 option.
238 -version:release
240 Specifies that the version specified by the release is required
241 by the class or JAR file specified on the command line. If the
242 version of the java command called does not meet this specifica‐
243 tion and an appropriate implementation is found on the system,
244 then the appropriate implementation will be used.
245 The release option specifies an exact version and a list of ver‐
246 sions called a version string. A version string is an ordered
247 list of version ranges separated by spaces. A version range is
248 either a version-id, a version-id followed by an asterisk (*), a
249 version-id followed by a plus sign (+), or a version range that
250 consists of two version-ids combined using an ampersand (&). The
251 asterisk means prefix match, the plus sign means this version or
252 greater, and the ampersand means the logical and of the two ver‐
253 sion-ranges, for example:
254 -version:"1.6.0_13 1.6*&1.6.0_10+"
255 The meaning of the previous example is that the class or JAR file
256 requires either version 1.6.0_13, or a version with 1.6 as a ver‐
257 sion-id prefix and that is not less than 1.6.0_10. The exact syn‐
258 tax and definition of version strings can be found in Appendix A
259 of the Java Network Launching Protocol & API Specification
260 (JSR-56).
261 For JAR files, the preference is to specify version requirements
262 in the JAR file manifest rather than on the command line.
263 See Notes for important policy information on the use of this
264 option.
265 Non-Standard Options
268 -X Displays information about nonstandard options and exits.
269 -Xint
271 Operates in interpreted-only mode. Compilation to native code is
272 disabled, and all bytecode is executed by the interpreter. The
273 performance benefits offered by the Java HotSpot Client VM adap‐
274 tive compiler is not present in this mode.
275 -Xbatch
277 Disables background compilation. Typically, the Java VM compiles
278 the method as a background task, running the method in inter‐
279 preter mode until the background compilation is finished. The
280 -Xbatch flag disables background compilation so that compilation
281 of all methods proceeds as a foreground task until completed.
282 -Xbootclasspath:bootclasspath
284 Specifies a colon-separated list of directories, JAR files, and
285 ZIP archives to search for boot class files. These are used in
286 place of the boot class files included in the Java platform JDK.
287 Applications that use this option for the purpose of overriding a
288 class in rt.jar should not be deployed because doing so would
289 contravene the Java Runtime Environment binary code license.
290 -Xbootclasspath/a:path
292 Specifies a colon-separated path of directories, JAR files, and
293 ZIP archives to append to the default bootstrap class path.
294 -Xbootclasspath/p:path
296 Specifies a colon-separated path of directories, JAR files, and
297 ZIP archives to add in front of the default bootstrap class path.
298 Do not deploy applications that use this option to override a
299 class in rt.jar because this violates the Java Runtime Environ‐
300 ment binary code license.
301 -Xcheck:jni
303 Performs additional checks for Java Native Interface (JNI) func‐
304 tions. Specifically, the Java Virtual Machine validates the
305 parameters passed to the JNI function and the runtime environment
306 data before processing the JNI request. Any invalid data encoun‐
307 tered indicates a problem in the native code, and the Java Vir‐
308 tual Machine will terminate with a fatal error in such cases.
309 Expect a performance degradation when this option is used.
310 -Xfuture
312 Performs strict class-file format checks. For backward compati‐
313 bility, the default format checks performed by the Java virtual
314 machine are no stricter than the checks performed by 1.1.x ver‐
315 sions of the JDK software. The -Xfuture option turns on stricter
316 class-file format checks that enforce closer conformance to the
317 class-file format specification. Developers are encouraged to use
318 this flag when developing new code because the stricter checks
319 will become the default in future releases of the Java applica‐
320 tion launcher.
321 -Xnoclassgc
323 Disables class garbage collection. Use of this option preven mem‐
324 ory recovery from loaded classes thus increasing overall memory
325 usage. This could cause OutOfMemoryError to be thrown in some
326 applications.
327 -Xincgc
329 Enables the incremental garbage collector. The incremental
330 garbage collector, which is turned off by default, will reduce
331 the occasional long garbage-collection pauses during program exe‐
332 cution. The incremental garbage collector will at times execute
333 concurrently with the program and during such times will reduce
334 the processor capacity available to the program.
335 -Xloggc:file
337 Reports on each garbage collection event, as with -verbose:gc,
338 but logs this data to a file. In addition to the information
339 -verbose:gc gives, each reported event will be preceded by the
340 time (in seconds) since the first garbage-collection event.
341 Always use a local file system for storage of this file to avoid
342 stalling the Java VM due to network latency. The file may be
343 truncated in the case of a full file system and logging will con‐
344 tinue on the truncated file. This option overrides -verbose:gc
345 when both are specified on the command line.
346 -Xmnsize or -XX:NewSize
348 Sets the size of the young generation (nursery).
349 -Xmsn
351 Specifies the initial size, in bytes, of the memory allocation
352 pool. This value must be a multiple of 1024 greater than 1 MB.
353 Append the letter k or K to indicate kilobytes, or m or M to
354 indicate megabytes. The default value is chosen at runtime based
355 on system configuration. See Garbage Collector Ergonomics at
356 http://docs.oracle.com/javase/7/docs/tech‐
357 notes/guides/vm/gc-ergonomics.html
358 Examples:
359 -Xms6291456
360 -Xms6144k
361 -Xms6m
362 -Xmxn
364 Specifies the maximum size, in bytes, of the memory allocation
365 pool. This value must a multiple of 1024 greater than 2 MB.
366 Append the letter k or K to indicate kilobytes, or m or M to
367 indicate megabytes. The default value is chosen at runtime based
368 on system configuration.
369 For server deployments, -Xms and -Xmx are often set to the same
370 value. See Garbage Collector Ergonomics at http://docs.ora‐
371 cle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics.html
372 Examples:
373 -Xmx83886080
374 -Xmx81920k
375 -Xmx80m
376 On Solaris 7 and Solaris 8 SPARC platforms, the upper limit for
377 this value is approximately 4000 m minus overhead amounts. On
378 Solaris 2.6 and x86 platforms, the upper limit is approximately
379 2000 m minus overhead amounts. On Linux platforms, the upper
380 limit is approximately 2000 m minus overhead amounts.
381 -Xprof
383 Profiles the running program, and sends profiling data to stan‐
384 dard output. This option is provided as a utility that is useful
385 in program development and is not intended to be used in produc‐
386 tion systems.
387 -Xrs
389 Reduces use of operating-system signals by the Java VM.
390 In an earlier release, the Shutdown Hooks facility was added to
391 enable orderly shutdown of a Java application. The intent was to
392 enable user cleanup code (such as closing database connections)
393 to run at shutdown, even if the Java VM terminates abruptly.
394 The Java VM catches signals to implement shutdown hooks for unex‐
395 pected Java VM termination. The Java VM uses SIGHUP, SIGINT, and
396 SIGTERM to initiate the running of shutdown hooks.
397 The JVM uses a similar mechanism to implement the feature of
398 dumping thread stacks for debugging purposes. The JVM uses
399 SIGQUIT to perform thread dumps.
400 Applications embedding the Java VM frequently need to trap sig‐
401 nals such as SIGINT or SIGTERM, which can lead to interference
402 with the Java VM signal handlers. The -Xrs command-line option is
403 available to address this issue. When -Xrs is used on the Java
404 VM, the signal masks for SIGINT, SIGTERM, SIGHUP, and SIGQUIT are
405 not changed by the Java VM, and signal handlers for these signals
406 are not installed.
407 There are two consequences of specifying -Xrs:
408 o SIGQUIT thread dumps are not available.
410 o User code is responsible for causing shutdown hooks to run, for
412 example by calling System.exit() when the Java VM is to be ter‐
413 minated.
414 -Xssn
416 Sets the thread stack size.
417 -XX:AllocationPrefetchStyle=n
419 Sets the style of prefetch used during allocation. default=2.
420 -XX:+AggressiveOpts
422 Enables aggressive optimization.
423 -XX:+|-DisableAttachMechanism
425 Specifies whether commands (such as jmap and jconsole) can attach
426 to the Java VM. By default, this feature is disabled. That is,
427 attaching is enabled, for example:
428 java -XX:+DisableAttachMechanism
429 -XXLargePageSizeInBytes=n
431 Specifies the maximum size for large pages.
432 -XX:MaxGCPauseMillis=n
434 Sets a target for the maximum GC pause time.
435 This is a soft goal, and the Java VM will make its best effort to
436 achieve it. There is no maximum value set by default.
437 -XX:NewSize
439 Sets the size of the young generation (nursery). Sames as -Xmn‐
440 size.
441 -XX:ParallelGCThreads=n
443 Sets the number of GC threads in the parallel collectors.
444 -XX:PredictedClassLoadCount=n
446 This option requires that the UnlockExperimentalVMOptions flag be
447 set first. Use the PredictedClassLoadCount flag if your applica‐
448 tion loads a lot of classes and especially if class.forName() is
449 used heavily. The recommended value is the number of classes
450 loaded as shown in the output from -verbose:class.
451 Example:
452 java -XX:+UnlockExperimentalVMOptions -XX:PredictedClassLoadCount=60013
453 -XX:+PrintCompilation
455 Prints verbose output from the Java HotSpot VM dynamic runtime
456 compiler.
457 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
459 Prints garbage collection output along with time stamps.
460 -XX:SoftRefLRUPolicyMSPerMB=0
462 This flag enables aggressive processing of software references.
463 Use this flag if the software reference count has an impact on
464 the Java HotSpot VM garbage collector.
465 -XX:TLABSize=n
467 Thread local allocation buffers (TLAB) are enabled by default in
468 the Java HotSpot VM. The Java HotSpot VM sizes TLABs based on
469 allocation patterns. The -XX:TLABSize option enables fine-tuning
470 the size of TLABs.
471 -XX:+UseAltSigs
473 The Java VM uses SIGUSR1 and SIGUSR2 by default, which can some‐
474 times conflict with applications that signal-chain SIGUSR1 and
475 SIGUSR2. The -XX:+UseAltSigs option causes the Java VM to use
476 signals other than SIGUSR1 and SIGUSR2 as the default.
477 -XX:+|-UseCompressedOops
479 Enables compressed references in 64-bit Java VMs.
480 This option is true by default.
481 -XX:+UseConcMarkSweepGC or -XX:+UseG1GC
483 Enables either the Concurrent Mark Sweep (CMS) or the G1 garbage
484 collectors.
485 -XX:+|-UseLargePages
487 Enables large page support.
488 Large pages are enabled by default on Solaris.
489 -XX:+UseParallelOldGC
491 Enables the parallel garbage collectors, which are optimized for
492 throughput and average response time.
493
496 The -version:release option places no restrictions on the complexity of
497 the release specification. However, only a restricted subset of the
498 possible release specifications represent sound policy and only these
499 are fully supported. These policies are:
500 1. Any version, represented by not using this option.
502 2. Any version greater than an arbitrarily precise version-id value,
504 for example:
505 "1.6.0_10+"
506 This would utilize any version greater than 1.6.0_10. This is
507 useful for a case where an interface was introduced (or a bug
508 fixed) in the release specified.
509 3. A version greater than an arbitrarily precise version-id, bounded
511 by the upper bound of that release family, for example:
512 "1.6.0_10+&1.6*"
513 4. An or expressions of items 2 or 3, for example:
515 "1.6.0_10+&1.6* 1.7+"
516 Similar to item 2. This is useful when a change was introduced in
517 a release (1.7) but also made available in updates to earlier
518 releases.
519
522 The following examples show how to use experimental tuning flags to
523 optimize either throughput or faster response time.
524 Example 1, Tuning for Higher Throughput
526 java -d64 -server -XX:+AggressiveOpts -XX:+UseLargePages -Xmn10g -Xms26g -Xmx26g
527 Example 2, Tuning for Lower Response Time
530 java -d64 -XX:+UseG1GC -Xms26g Xmx26g -XX:MaxGCPauseMillis=500 -XX:+PrintGCTimeStamps
531
534 The following exit values are typically returned by the launcher, typi‐
535 cally when the launcher is called with the wrong arguments, serious
536 errors, or exceptions thrown from the Java Virtual Machine. However, a
537 Java application may choose to return any value using the API call Sys‐
538 tem.exit(exitValue).
539 o 0: Successful completion
541 o >0: An error occurred
543
546 o javac(1)
547 o jdb(1)
549 o javah(1)
551 o jar(1)
553 18 Jul 2013 java(1)