java.exe : Java Glossary

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 )

Long Command Lines

• Specify classpath as SET CLASSPATH= rather than a command line option -cp .
• Write a little kicker program in C or Java that exec’s java.exe with the command line. That way it can be arbitrarily long.
• Use tcc/TakeCommand or 4DOS. It lets you have lines 1023 characters long, and provides for line continuation.

CLASSPATH And File Naming Recipes

1. Use Java version 1.1 or later. Configure your SET SET CLASSPATH= to clear it out. Avoid JDK (Java Development Kit) 1.0 if you can because its CLASSPATH is more complicated since it has to help java find the standard classes.
2. In all that follows, everything is strictly case sensitive.
3. To run a HelloWorld.class app, in the default package in C:\MyDir, use

   CD \MyDir
   java.exe -ea -classpath . HelloWorld

   Note 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.
4. The following will not work to run a HelloWorld.class app, in the default package
5. To run a HelloWorld.class app in C:\com\mindprod\mypackage, in package com.mindprod.mypackage, use

   CD \
   java.exe -ea -classpath . com.mindprod.mypackage.HelloWorld

6. The following will not work to run a HelloWorld.class app in C:\com\mindprod\mypackage, in package com.mindprod.mypackage:

   CD E:\com\mindprod\mypackage
   java.exe -ea -classpath . com.mindprod.mypackage.HelloWorld

   For that to work, you must use smartj instead of java.exe.

7. The following will not work to run a HelloWorld.class app in

8. 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

9. If for any reason the examples shown do not work with your version of java.exe, try various combinations of com.mindprod.mypackage.HelloWorld, com/mindprod/mypackage/HelloWorld and com\mindprod\mypackage\HelloWorld.

The Java.exe Command Line

• Note, unlike with javac.exe or <APPLET CODE, you don’t specify the extension (.class).
• Note, unlike all other command line utilities in the universe, you cannot specify the fully qualified filename of the class file. You must however specify the full package name.
• The CLASSPATH must provide access to all the needed *.class, *.zip and *.jar files.
• If you want to run an Applet you need to use AppletViewer or a browser instead of java.exe, and you need to compose some HTML (Hypertext Markup Language) with an <APPLET tag in it.
• The switches are case sensitive.
• Make sure you specify the -options before the name of the class you want to execute, otherwise they will be interpreted as parameters to your main method.
• If you use the -jar option, the java.exe ignores the classpath. It will only look in that jar. You can’t specify a class. You must use the Main-Class specified in the manifest. If there is no Main-Class, then nothing will work. To execute some other class besides the Main-Class, don’t use -jar ; put the jar on the classpath instead.
• With JDK 1.4.2 the command line switches had a major overhaul. Many of the old switches no longer work.

set jopts=-Xms4m
...
java.exe %jopts% MyClass

_JAVA_OPTIONS

Parameters with Embedded Blanks

On windows you can enclose your blank-containing parameters in "s and they will be stripped off before your main program sees them.

Awkward Characters in Command Line Parameters

• Parameters cannot begin with - since those are for java.exe itself. So you must enclose such parameters inside quotes, e.g.

  java.exe -ea -jar myjar.jar "-something"

• Since spaces separate parameters, you can’t have spaces inside parameters unless you surround them in quotes, e.g.

  java.exe -ea -jar myjar.jar "new improved blue raspberry flavour"

• Since quotes surround parameters, you can’t have quotes inside parameters unless you precede them with

  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.
• Somebody was asleep at the switch when they devised this convention.

  java.exe -ea -jar myjar.jar "F:\Program Files\"

  That is illegal! and you can’t specify it another way.
• You can’t have newline characters inside your parameters. If you need them, you will need to cook up some encoding scheme of your own, perhaps URLEncoder, and explicitly decode that parameter yourself.
• You can’t have any character you cannot key in the native encoding in which you write your bat stream. If you need them, you will gain have to roll your own scheme to pass them through.

Jars

Multiple java.exes

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\jre7 \bin or sun.boot.library.path=J:\Program Files\java\jdk1.7.0_21 \bin to determine which one is being used. For explicit control, type "C:\Program Files\java\jre7\bin\java.exe" or "J:\Program Files\java\jdk1.7.0_21\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.

How do you select which java.exe to run?

Here are some possible ways:

• Put the java.exe you want first on the path.
• Explicitly invoke the Java.exe you want e.g. J:\Program Files\java\jdk1.7.0_21 \bin\java.exe.
• Fiddle with the Java control panel to hide the Javas you do not want to use.
• Use the java.exe -d32 and -d64 options to guide it to right java.exe
• Use the java.exe -version option.
• You could fiddle with the registry to switch JVMs (Java Virtual Machines). See the JVM Manager student project. However, there is a simpler, cruder way.
  1. Delete the copy of java.exe and javaw.exe in C:\WINDOWS\system32 or C:\WINNT\system32.
  2. Define a SET JAVA_HOME=C:\Program Files\java\jre7 (no quotes!) environment variable to point to the where the \bin directory is containing the java.exe you want to use.
  3. Make all references in your bat files to your JVM use %JAVA_HOME%\bin\java.exe, ditto for javaw.exe and javac.exe.
  4. Change JAVA_HOME to switch JVMs. Unfortunately, IE (Internet Explorer), Opera and Netscape won’t pay any attention to you.
• Instead of using java.exe repeatedly in a batch file, it is much more efficient (i.e. faster) to write a tiny Java program that just invokes the main methods of the various steps in turn. That way you only have to load the JVM once. You can use exec to handle that which you still want to do in BAT (Batch) files. You are reversing the roles, Java calling BAT files rather than BAT files calling Java. You will find many task are easier in Java that BAT language.

Aborting

Under the Hood

Learning More