When you're running applets from within a Web browser, you don't have to be concerned with the Java interpreter and how it executes Java programs. However, the only way to run Java Standalone applications is by loading them directly into the interpreter. These means typing a command line in much the same way you did for compiling files. The command line not only tells the Java interpreter which program you want to run, but also the command-line options you want to use when running the program. In this chapter, you study the Java interpreter in detail.
As you learned in the previous chapter, the Java compiler converts your Java source code into a .CLASS file. Unlike the files created by a C compiler, which creates output files that are executable only on a specific type of computer, this .CLASS file is in a special format that is transportable between various computer systems. A .CLASS file contains byte-code information that represents the commands in your original source code.
The key to this intersystem transportability is the Java interpreter. Although a Java byte-code file can be run on any Java-compatible system, the Java interpreter must be created specifically for each system that needs to run Java programs. Therefore, the Java interpreter for the Macintosh will not run on a Windows system, even though both systems can execute the same byte-code file.
In the previous chapter, you saw a figure that illustrated the relationship between Java source-code files, compilers, byte-code files, and the different interpreters. Figure 35.1 reprints that figure for your convenience in this discussion.
Figure 35.1 : The relationship between the various components of the Java system.
When the user installs Java on his system, he must install the correct version for that system. Once the installation is complete, the user can connect to the Internet and view any Java applets that may be contained in the Web pages he downloads. These applets are interpreted and executed automatically by Java, thanks to the connection between the Java-compatible browser and the Java system.
The only time the user must be concerned with the interpreter directly is when he wants to run a Java application, which is represented in the same kind of byte-code (.CLASS) file as an applet. The difference is that Java standalone applications cannot be executed from within a Web browser. Instead, the user runs them from his system's command line, invoking the interpreter "by hand," as it were.
In Chapter 32, "Writing Java Applications," you got a brief look at the process of creating and running Java standalone applications. In that chapter, you learned that you can run a Java application with the following command:
java filename
In this command, filename is the name of the application's .CLASS file. For example, if you wanted to run an application called MyApp, your command line would look like this:
java MyApp
Notice that, unlike the compiler, the interpreter doesn't require the source file's extension. In fact, if you include the file extension, the interpreter generates an error (Figure 35.2). This is because the interpreter is not able to tell the difference between a fully qualified class name (which uses dots) and a file name with an extension (which also uses a dot). Also, the interpreter expects upper- or lowercase letters in a file name. The file name MyApp, MYAPP, and myapp are all different to Java's interpreter.
Figure 35.2 : Unlike the compiler, the Java interpreter will not accept file extensions.
Like the compiler, the Java interpreter recognizes a set of command-line
options that you can use to tailor the how the interpreter runs.
Those options are listed in Table 35.1.
| Option | Description |
| -checksource | Instructs the interpreter to run the compiler on files that are not up to date. |
| -classpath path | Determines the path in which the compiler looks for classes. |
| -cs | Same as -checksource. |
| -D | Instructs the interpreter to set a property value. |
| -debug | Runs the debugger along with the application. |
| -help | Displays the commands you can use with the interpreter. |
| -ms x | Specifies the amount of memory allocated at startup. |
| -mx x | Specifies the maximum amount of memory that can be allocated for the session. |
| -noasyncgc | Tells Java not to use asynchronous garbage collection. |
| -noverify | Tells the interpreter not to verify code. |
| -oss x | Specifies the maximum stack size for Java code. |
| -ss x | Specifies the maximum stack size for C code. |
| -v | Specifies that the interpreter should display status information as it works. |
| -verbose | Same as -v. |
| -verbosegc | Specifies that the garbage collector should display status information as it works. |
| -verify | Tells the interpreter to verify all Java code. |
| -verifyremote | Tells the interpreter to verify code loaded by a classloader. This option is the default. |
As you can see, the interpreter can accept quite a few command-line options. Of these options, though, only a few are used frequently. You'll get a look at those more useful options in the sections that follow.
When you're working on a new application, you'll make frequent changes to the source code. Whenever you change the source code, you must recompile the program before you run it. Otherwise, you'll be running an old version of the program. When you start writing larger applications, you'll have many files for the classes that are used in the program. As you change the contents of these files, you may lose track of which files need to be recompiled. This is where the interpreter's -checksource command-line option comes into play.
The -checksource option tells the interpreter to compare the dates and times of your source-code files with the dates and times of the matching .CLASS files. When a source-code file is newer than the matching .CLASS file, the interpreter automatically runs the compiler to bring the files up to date. You use the -checksource option like this:
java -checksource appname
Here, appname is the name of the class you want the interpreter to run.
| NOTE |
When running a standalone application, any arguments that you place after the name of the file to execute are passed to the application's main() method. For more information on handling these application arguments, please refer to Chapter 32, "Writing Java Applications." |
In order to run a standalone application, the interpreter usually needs to load class files that are used by the program. These files might be files that you've created for custom classes or they may be the class files that make up the class hierarchy of the class you're executing. When you derive your applet from Java's Applet class, for example, the interpreter needs to load the Applet class, as well as Applet's superclasses, in order to run your application. Before the interpreter can access these class files, it has to know where they are.
Normally, when you run a program, the interpreter finds classes using the current setting of your system's CLASSPATH variable, whose default value is the folder that contains Java's classes. Java will also look in the active folder (the one you're in when you type the java command line). However, you can change the setting of CLASSPATH temporarily for the current program run by using the -classpath option, like this:
java -classpath path FileName
In the preceding line, path is the path you want to include, each separated by a semicolon. For example, assuming that you installed Java in a folder called C:\JAVA and that your own classes are in the C:\CLASSES folder, the following line runs your program using the same settings the interpreter would use by default:
java -classpath c:\java\lib\classes.zip;c:\classes FileName
Notice that Java's classes are in a file called CLASSES.ZIP. You must include this file name in the path in order for the interpreter to find the classes it needs to successfully run your applet.
When you run the Java interpreter with no command-line option, the compiler runs and performs its task without displaying information on the screen. Sometimes, though, you may want to know what files the interpreter is loading and where those files are being loaded from. You can make the interpreter report to you as it works by using the -verbose option, like this:
java -verbose applet.java
To see what happens when you use the -verbose (or -v) command-line option, copy the SimpleApp.class file from the CHAP35 folder of this book's CD-ROM to your CLASSES folder. Then start an MS-DOS session and type the following command at the prompt:
java -verbose SimpleApp
When you press Enter, the interpreter runs, loading the application and displaying all the additional files it has to access in order to run the application. Figure 35.3 shows a portion of this output. Bet you didn't expect such a simple program could make the interpreter work so hard!
Figure 35.3 : The -verbose option enables you to see what files are being loaded by the interpreter.
| TIP |
A special version of the Java interpreter can trace and display every command that's executed in your application. (You can find this tool in your JAVA\BIN folder, along with the other Java tools.) To invoke this special option, type java_g -t AppName at your system prompt. The AppName portion of the command is the name of the .CLASS file you want to run, without the file extension. Figure 35.4 shows a small portion of the output generated by this command. Even a small application results in many pages of trace information. |
Figure 35.4 : The java_g -t command displays every command executed in your application.
The Java interpreter has a long list of command, so you'll probably have a hard time remembering them all. Luckily, you can get a quick reminder of what the commands are and what they do. To get this information, type the following command:
java -help
When you do, you'll see the display shown in Figure 35.5. For more information than is displayed in the help listing, check this chapter or your online Java documentation.
Figure 35.5 : The Java interpreter features a built-in help display.
When you are using a Java-compatible Web browser to view applets, you don't need to be concerned with the Java interpreter. The browser displays the applets for you automatically. However, if you want to run a standalone Java application, you must invoke the interpreter from your system's command line. The interpreter accepts over a dozen different command-line options, although only a few are regularly useful to novice and intermediate Java programmers.