Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp .com.
Notice: This material is excerpted from Special Edition Using Java, ISBN: 0-7897-0604-0. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Some programming languages, such as C and Fortran, are compiled languages: the source code is compiled into machine code that is unique to the target hardware platform and operating system. Other languages, such as like APL and lisp, are interpreted languages: the source code is executed by running it through an interpreter. Both approaches have their strengths and weaknesses. Compiled programs tend to be faster and more efficient, but the compiled program can be run on only one hardware platform and operating system. Interpreted programs tend to be less efficient but potentially can be run, without change, on any platform for which an interpreter exists.
Java is both compiled and interpreted. The Java compiler, called javac, compiles (translates) the Java source code into an intermediate-level code called byte codes. These bytecodes are not directly executable on any hardware platform that is currently in existence; rather, the codes are interpreted by the Java interpreter, which can operate either by itself or as part of a Web browser such as Netscape.
The fact that Java is both compiled and interpreted can give you, the Java programmer, the best of both worlds. A program that you write in Java will be efficient (because it is compiled) and capable of running on a multitude of platforms (because it is interpreted).
In this chapter, you learn the following:
The installation process that you completed in chapter 3 creates a hierarchy of directories, beginning with a directory called java. When we installed Java on our system, we put the java directory below a root-level directory called Languages, but you can put yours wherever you think is best, including directly below the root. After installation, then, we have the following directories on our machine:
See installing the Java Development Kit, Appendix D
Directory What you'll find there
The javac compiler resides in the \java\bin directory.
Remember that UNIX uses a forward slash (/) where DOS uses a back slash (\). On a UNIX machine, then, the path to the javac compiler would be something like /java/bin/javac, while on a DOS machine, it would be something like \java\bin\javac. The main java directory could be somewhere other than directly below the root.
Most modern compilers are optimizing compilers. After an optimizing compiler has performed the translation step (translating source code into object code) it goes through an additional step in which the object code is optimized either to use memory more efficiently, or to use less CPU time, or both. The Java compiler comes in two forms. The javac compiler is an optimizing compiler and is the one you will usually use. The javac_g compiler is a nonoptimizing version and is intended primarily for debugging purposes, generating bytecodes for interpretation by jdb or some other compatible debugger.
Both compilers, javac and javac_g, have the same syntax, so everything that this chapter covers applies equally to both compilers. The chapter uses javac in all its examples, but you could use javac_g in exactly the same ways.
You invoke the javac compiler from the command line. The general syntax is as follows:
javac [ options ] filename
The options govern the behavior of the compiler. The file name is the name of the file that contains the Java source code that you want to compile. The javac compiler requires that source code be contained in files whose names end with the .java extension. Because the options are not required (they really are options; they're optional!), the following example is a valid invocation of the compiler:
javac HelloWorldApp.java
If all goes well-meaning, in this example, that HelloWorldApp.java contains valid Java source code for a class called HelloWorldApp-the javac compiler compiles the source code into Java bytecodes and stores the output in a file called HelloWorldApp.class.
Suppose that you want to create a file called HelloWorldApp.java, containing the code as shown in listing 3.1.
Listing 3.1-HelloWorldApp.java
class HelloWorldApp
{
public static void main (String args[])
{
System.out.println ("Hello, world!");
}
}
Listing 3.1 A simple "Hello World" Java application.
Don't worry too much about what all the code means; we'll be covering the syntax for the language in detail in part two of this book (chapters 7 through 15).
figure 3.1 shows what happens when you use javac to compile this program and then use java, the Java interpreter, to run it.
See Java in "the Java Environment Tools" Chapter 2
fig. 3.1 The javac compiler reads in the .java file and generates the .class file from it, ready for interpretation by java, the Java interpreter.
File Extensions
C and C++, like many other languages, have certain conventions and defaults for the names of your files. File names that end with .c might be C source code files; those that end with .cpp might be C++ source code files; and those that end with .obj might be object code files. For most C and C++ development systems, these defaults are easy to override. The rules in Java programming, however, are not so easy to break:
As you learned earlier in this chapter, the byte codes that are generated by the javac compiler are stored in a file with the extension.class. These .class files are roughly equivalent to the .obj object files or .exe executable files that are generated by other compilers. The difference, of course, is the fact that the .class files contain not machine language but byte codes that are ready for interpretation by the Java interpreter.
By default, the .class files are created in the same directory as the .java source file, but this default is easy to change. If you want to store your .class files elsewhere, you can use the -d option of the javac command to have the compiler create the .class files elsewhere. Consider the following example:
javac -d MyClasses HelloWorldApp.java
In this case, the .class file generated by javac is stored in the MyClasses directory.
Some operating systems, such as UNIX, use permissions on directories (and on files, for that matter) to determine what kinds of access you have. When the javac compiler generates its output, it must create the .class file. Make sure that you have permission to create files (in UNIX, write permission) in the directory in which the Java compiler is to generate the .class file.
Take a moment to consider how regular executable programs are invoked from the command line. When a user of MS-DOS or UNIX types the name of a program on the command line and presses Enter, the command interpreter looks for an executable program of the specified name and, if it finds that program, loads the program into memory and begins execution. The PATH variable determines where the command interpreter looks for the executable program.
A very similar situation exists in Java. The only problem is that Java programs are not executable in the traditional sense; they are loaded and executed directly by the Java interpreter, by a browser such Netscape, or by a utility such as AppletViewer (part of the Java development kit). Because these files aren't executable by the operating system, the PATH variable isn't going to help you.
Where the operating system uses the PATH variable to find executables, Java uses the CLASSPATH variable to find classes. The CLASSPATH variable is a list of directories, delimited either by semicolons (Windows 95 or Windows NT) or colons (UNIX). Java searches these directories, in order, for the appropriate .class file.
The CLASSPATH variable isn't of interest only to the run-time system. As you see in later chapters, Java classes often depend on one another for much of their functionality. If you are creating your own classes to be used by other classes, you must tell the compiler know where to find those classes, just as you would tell the interpreter. When the javac compiler needs to load one of your classes, it searches, in order, through the directories listed in the CLASSPATH variable.
The directory that holds the system classes (\java\lib, for example) always is appended to your CLASSPATH variable. In other words, you should have to specify directories in CLASSPATH only for additional classes that you create.
If you are using a PC running Windows, for example, you might add the following line to your autoexec.bat file to add the \project\classes directory to the CLASSPATH variable:
Remember that changes to the autoexec.bat file don't take effect until you reboot your computer. Be sure to reboot after adding the above line to your autoexec.bat.
Permanent settings for the CLASSPATH variable normally are set in an autoexec.bat file or (on UNIX systems) in a shell startup file such as .profile. For a temporary change of CLASSPATH, you can use the -classpath option in the javac compiler. The directory list specified in the -classpath option temporarily overrides the contents of the CLASSPATH variable. Note that in the following example we've explicitly included the location of the system classes:
javac -classpath .;C:\java\lib\classes.zip;C:\develop\classes Payroll.java
In this example, java compiles the file Payroll.java and, if necessary, searches the current directory, followed by the system library (C:\java\lib\classes.zip) followed by C:\develop\classes, for any additional classes. The equivalent command on a UNIX system would be:
javac -classpath .:/java/lib/classes.zip:/develop/classes Payroll.java
In order to conserve disk space (and to save time when downloading), the system classes are now supplied in one archive file called classes.zip. The Java run-time system and the javac compiler are both able to search for classes in directories, or in .zip archives.
The syntax for the CLASSPATH variable or for the -classpath argument is similar to the syntax for the PATH variable in DOS or UNIX. For PC users on Microsoft platforms, the path is a list of directories separated by semicolons (;). For UNIX users, the path is a list of directories separated by colons (:).
Two options in the compiler affect the kinds of messages that the compiler generates:
The -verbose option also is available in the java interpreter. The option causes the interpreter to display a short message each time it loads a new class file.
The final two compiler options effect the kind of output generated by javac:
Inlining is a technique that is familiar to C++ programmers. When a method or function is compiled inline, its code is generated at the location where the method is invoked, which means that the code will be executed at run-time without the additional overhead of a function call.
The best place to consider inlining is when short methods are invoked many times from one location in the source code (like a method invoked from within a loop that is repeated many times). In such a situation, the overhead associated with the method invocation will be high when compared to the total processing for the method.
Because code for inlined methods is duplicated at each place where the method is invoked, the resulting code can be larger and can require more memory in which to run.
Here are some of the common problems that you might encounter with the Java compiler, especially when you are using it for the first time.
If you attempt to invoke the javac compiler and get the error message file not found (in UNIX) or Bad command or file name (in Windows), you probably did not set your PATH variable correctly. The operating system uses this variable to determine where to look for programs such as javac. Your PATH is set in the autoexec.bat file (on PC platforms) or in a startup script such as .profile (on UNIX systems). The PATH variable must contain the name of your Java bin directory.
On a DOS system, remember to reboot your system to have the changes to the autoexec.bat take effect. If you are on a UNIX system, be sure to log out and log back in again to have the changes to your .profile take effect.
If you get any of the following error messages, the compiler is unable to locate either your classes or the system classes:
This problem has several possible causes. If you are getting error messages like the ones in the preceding list, try the following procedures:
Recall the earlier example of a possible DOS command:
javac -classpath .;C:\java\lib\classes.zip;C:\develop\classes Payroll.java
And the equivalent UNIX command:
javac -classpath .:/java/lib/classes.zip:/develop/classes Payroll.java
Many DOS-based unzip programs do not correctly handle long file names. Such utilities will truncate the names of the classes contained in classes.zip. Either leave the classes.zip as-is in its zipped state-or be sure to unzip it with a utility that understands long file names.
A .zip file is an archive; it can potentially contain many other files or directories. The .zip file format was initially popularized on the PC, but is now supported on a wide variety of operating platforms. To "unzip" a .zip file means to extract the component files from the archive. The Java system classes come in a .zip file-an archive-called classes.zip. There is no need to unzip this archive.
Like all compilers everywhere in the world, javac is very adept at reporting syntax errors, such as misspellings, missing punctuation, and incorrect use of keywords. In all these cases, the compiler lists the error and attempts to direct you to the appropriate line of code. Keep in mind, however, that errors on one line of code sometimes won't be discovered until a line or two later. If the line javac to which javac is directing you seems to be perfectly OK, check the few lines before it; a more subtle error may be lurking in those lines.
Like all software, javac (and the rest of the JDK) contains a few bugs-problems that weren't caught before the software was released. Sun maintains a list of the known bugs. Checking this site periodically is worthwhile; you can see whether the trouble that you are having has already been reported by someone else.