8. Compiling Java Classes
Key concepts
- Tools of the trade: editor, compiler, debugger
So far, we've seen one tool of the trade, which we've called the interpreter. This works well for testing out small chunks of code or experimenting with expressions. Many interpreters are unable to interpret class definitions, so we require a slightly different methodology. The programmer [you] type your class definition into a text file, using a text editor. At some point, you give your source code to another program called a compiler. The compiler reads your source code and translates it into a representation that is understandable by a machine. Notice the difference between the interpreter we've been using and a compiler. The interpreter is just like a real language interpreter, who might interpret, sentence-by-sentence a conversation you are having with a speaker of another language. The compiler is more like a translator. Given a document [in our case, containing Java source code], the translator translates it from one language to another [in our case, a kind of machine language].
There are many fancy software development environments on the market. Many of them are great at what they do, and we're not particularly religious at using a certain one. However, we do believe that they tend to make the fundamental steps of writing a program seem much more complicated than they really are. A programmer really does the following [at a minimum]:
- Edits her source code [using an editor]
- Compiles her source code [using a compiler]
- Possibly repeats steps 1 and 2 if there are syntax/semantic errors
- Runs her program
- Possibly [probably] goes back to step 1 to improve and/or fix the program.
| Editor [e.g. Emacs] | Keystrokes and mouse input | A Java source file [e.g. MyCode.java] |
| Compiler [e.g. javac] | A Java source file [e.g. MyCode.java] | A Java class file [e.g. MyCode.class] |
| A Machine [e.g. java] | A Java class file [e.g. MyCode.class] | The result of your program! |
The following image shows the relationship between the tools and the files they consume and produce:
Ok, so what does a Java source file look like? Generally, a Java source file contains just a class definition. Let's take a look at an example class definition for BankAccount. Notice that this particular version of BankAccount only understands two methods: assessCheckingFee and deposit.
class BankAccount { int number; double balance String name; void assessCheckingFee[] { this.balance = this.balance + 3.0; } void deposit[double amount] { this.balance = this.balance + amount; } }Try using a text editor to type in the above code into a file called BankAccount.java. Notice that we've given the file the same name as the class definition it contains. Next try to compile it. If your file looks like the one above, it shouldn't compile. It won't compile because it contains a syntax error. The compiler will complain and helpfully tell us where it discovered the syntax error, with a message like this:
When you execute the above statements, is the result what you expected? Do you notice that something seems wrong with the balance of the account? This is a kind of error that the Java compiler cannot catch. It's a logic error in your program. It's like giving someone directions and telling them to go right instead of left at a critical intersection. The directions are perfectly understandable, but they don't get you to where you want to go. Programmers call this a "bug" in the program. In this case, the bug is that the assessCheckingFee method adds three dollars to the account rather than subtracting that amount. Clearly - from the banker's perspective, at least - this does not yield the intended result.
Let's fix the bug. We do so by again making the required changes to the code [in this case, just changing the '+' to a '-', and re-saving the file. We then re-compile the file, re-start the interpreter, and test the class as we did above.
Ben Dugan & UW-CSE, Copyright [c] 2001.