|Long Command Lines||Multiple java.exes|
|CLASSPATH And File Naming Recipes||Aborting|
|The Java.exe Command Line||Under the Hood|
|_JAVA_OPTIONS||Default File and Console Encoding|
|Parameters with Embedded Blanks||javac.exe|
|Awkward Characters in Command Line Parameters||Learning More|
The other thing to understand is that java.exe and javac.exe were written by two different teams of people who never had coffee together. That’s why the command line switches are so infuriatingly inconsistent.
All applications that you run with java.exe (such as HelloWorld.java ) must
public static void main ( String args )method.
CD \MyDir java.exe -ea -classpath . HelloWorldNote that the -classpath must come before the HelloWorld classname. To remember the order, you can think of it like this. java.exe needs to know the classpath before it can search for the class. If you get them reversed you will just get a mysterious NoClassDefFoundError.
CD \ java.exe -ea -classpath . com.mindprod.mypackage.HelloWorld
CD E:\com\mindprod\mypackage java.exe -ea -classpath . com.mindprod.mypackage.HelloWorldFor that to work, you must use smartj instead of java.exe.
The following will not work to run a HelloWorld.class app in
The following will work to run a HelloWorld.class app in
REM For this to work, you must specify the class to execute, REM com.mindprod.mypackage.HelloWorld in the manifest Main-Class entry. CD \AnyDir java.exe -ea -jar HelloWorld.jar
|Java.exe command line switches|
|-help||print out info on options. Trust what it says over what I say here. Knowledge keeps no better than fish.|
|-d32||use 32 bit JVM if possible.|
|-d64||use 64 bit JVM if possible.|
|-ea||Turn on assertion checking.|
|-version||print out the build version. Can also be used to specify the version you want.|
|-verbose||turn on verbose mode.|
|-verbose:class||display the name of each class as it is loaded.|
|-server||use the version of the JVM optimised for server apps. This only works with the private JRE java.exe that comes with the JDK in J:\Program Files\java\jdk1.8.0_05 /bin/java.exe, not the public JRE in C:\Program Files\java\jre8 /bin/java.exe.|
|-client||This is the default. Use the version of the JVM optimised for client apps|
|-Xint||Use a pure interpreter, not the Hotspot JIT.|
|-XX:MaxPermSize=64m||Size of the permanent generation memory pool in megabytes for long lived objects.|
|-XX:+PrintOptoAssembly||Display the generated assembly code, not the byte code, the CPU-specific assembly code generated by HotSpot.|
|-XX:xxxx||There are many extended esoteric options|
|-debug||enable remote JAVA debugging. For ordinary debugging, you probably want -verbose or -g instead.|
|-g||include debug code to create stack traces with variable names and line numbers.|
|-javaagent:myagent.jar||define a jar containing a java.lang.instrument agent to use for monitoring code. Java version 1.5 or later. Note the quirky extra colon.|
|-Xincgc||Use incremental garbage collection. You have shorter pauses, but it takes 10% more overhead.|
|-XX:+DoEscapeAnalysis||The option directs HotSpot to look for objects that are created and referenced by a single thread within the scope of a method compilation. Allocation is omitted for such non-escaping objects, and their fields are treated as local variables, often residing in machine registers. Synchronization on non-escaping objects is also elided.|
|-XX:+UseCompressedOops||The option can improve performance of the 64-bit JRE when the Java object heap is less than 32 gigabytes in size. In this case, HotSpot compresses object references to 32 bits, reducing the amount of data that it must process.|
|-XX:+UseParNewGC||Use concurrent garbage collection to avoid pauses.|
|-verbosegc||print a message when garbage collection occurs.|
|-noclassgc||disable class garbage collection.|
|-Xss64k||set the maximum native stack size for any thread, in 1024 byte chunks.|
|-Xoss300k||set the maximum Java stack size for any thread, in 1024 byte chunks.|
|-Xms2000m||set the initial Java heap size, in megabytes. g/gigbytes are not supported. The default is computed based on the system configuration.
You can burn this, and similar java.exe switches in at compile time with the
javac.exe -J switch. You can also put them into a
SET parameter and |
set jopts=-Xms4m ... java.exe %jopts% MyClass
|-Xmx5000m||set the maximum Java heap size, in megabytes. g/gigbytes are not supported. The default is computed based on the system configuration.
When tweaking the memory configuration options, try a variety of constellations of options to discover which actually works better. Bigger is not necessarily better. What is best depends on your hardware and what else in running in your machine at the time. It would be nice if there were some utility that could automatically tweak these parameters depending on the current conditions and past history.
|-cp .;C:\java\classes.zip…||list directories in which to look for classes. It is sometimes spelled out longhand -classpath. Infuriatingly, javac.exe won’t let you use the -cp shortcut. Starting with Java version 1.2 you don’t add classes.zip, (or rt.jar) to the classpath.|
|-jar C:\java\myjar.jar…||Names jar to look inside for class files. This jar must have a manifest Main-Class which gives the name of the class to execute. You may not specify it on the command line.|
|-prof:java.prof||output profiling data to .\java.prof.|
|-verify||verify all classes when read in.|
|-verifyremote||verify classes read in over the network.|
|-noverify||do not verify any class.|
|-Xfuture||Recommended to test all class files for strict conformance with coming mandatory standards.|
On windows you can enclose your blank-containing parameters in "s and they will be stripped off before your main program sees them.
java.exe -ea -jar myjar.jar "-something"
java.exe -ea -jar myjar.jar "new improved blue raspberry flavour"
java.exe -ea -jar myjar.jar "She said, \"I'm leaving\"."Backslash in any other context just means plain backslash. Unlike in Java String literals, you don’t double each backslash.
java.exe -ea -jar myjar.jar "F:\Program Files\"That is illegal! and you can’t specify it another way.
To complicate things further the java.exe in system32 is just a dummy. It looks in the registry and then decides which real java.exe to use. The last JVM installed gets to be the one used, even if it is older. To switch JVM s, you must normally reinstall the one you want.
I have found that sometimes, if you just type plain java.exe you will get the JDK version and sometimes the JRE version. I think Sun may have switched horses at some point. It used to be the JRE, but now it seems to be the JDK. You can look at the system property sun.boot.library.path= C:\Program Files\java\jre8 \bin or sun.boot.library.path=J:\Program Files\java\jdk1.8.0_05 \bin to determine which one is being used. For explicit control, type "C:\Program Files\java\jre8\bin\java.exe" or "J:\Program Files\java\jdk1.8.0_05\bin\java.exe"
If you explicitly invoke the JRE java.exe, it just executes, without checking the official JRE, since it notices it is living in a JRE directory.
If you explicitly invoke the JDK java.exe, it just executes, without checking the official JRE. Further, it has additional support for the -server option that the JRE java.exe lacks.
Here are some possible ways:
available on the web at:
optional Replicator mirror
Your face IP:[188.8.131.52]
|Feedback||You are visitor number 166,493.|