Follow the steps in Appendix A to download and install a Java Development Kit (JDK). The current version of the JDK is called "J2SE version 5", i.e. Java 2 Standard Edition version 5 of the Software Development Kit. During beta testing, this release was called version 1.5, and you may still hear old timers call it "JDK 1.5". It was promoted to version 5 in recognition of the large number of core language changes in the release.

A lot of programmers use IDEs to develop their code, and there are many IDEs that support Java, including some free ones such as Sun's NetBeans, Eclipse, or the BlueJ environment. You can get a list by googling for “Java IDE”. We'll avoid IDEs here and do everything from the command line, to keep the learning experience focused on Java. Create a separate work directory just for your files, and don't put your directory anywhere under the JDK installation directory.

After installing, you can run the Java compiler. Type this at the command shell:

Assuming you installed the JDK and set the path correctly, you will get back a dozen lines of messages, starting with this line:

Voila, your first Java program (no file at all, which is even easier than "hello world") compiles OK. If you saw something different, like "javac not recognized", troubleshoot your installation and/or the path variable as outlined in appendix A.

The next step is to run a Java program. Java was originally implemented as an interpreted language. You ran the interpreter program, the interpreter read the bytecode, and interpreted it into the corresponding instructions for that architecture.

And that's still mostly true today for most implementations of Java. Sun refers to the interpreter program as the Java Virtual Machine (JVM). The JVM, the run-time library, and the extensive Java libraries together are known as the Java Runtime Environment (JRE). The JRE does for Java applications roughly what Microsoft's Common Language Runtime (CLR) does for .net applications. The CLR lets a program be written in any of several Windows languages and only run on Windows. The JRE lets a program (in any language that compiles to Java bytecode) run on every computer system.

That truly means Java runs on just about every computer system. Cell phones and digital cameras today contain general-purpose microprocessors, which is the main reason there's a few seconds ofdelay after turning them on—they take time to boot up. I haven't written a Java program for my digital camera yet, but there are plenty for my cell phone.

Interpreter performance boosts

A classic interpreter has a start-up performance issue: instead of the operating system loading your program into memory and executing it, the operating system has to load the interpreter program into memory and execute it, followed by the interpreter program loading the run-time library and your program into memory and executing that. So interpreted programs have twice the start-up overhead of programs that have been compiled to native code. This doesn't matter for server code, but has dampened Java's popularity for desktop applications.

Class data sharing

A huge amount of effort has been devoted to speeding up Java and the JVM interpreter. JDK 1.5 brings in a new and significant optimization called class data sharing. This technique maps most of the run-time library into the JVM as a memory image, rather than loading it from a series of class files. Although memory mapped I/O is fast (see Chapter 18 for details), it makes the process look bigger to some Windows tools (wrongly) than if you had loaded the same content through the link-loader.

Footprint reduction

Also in JDK 1.5, as much as possible of the run-time library (several MB) is now shared among JVM instances, rather than loaded into each individually. This will improve performance when you run several Java programs at once. Everyone hopes that class data sharing will give great results, rejuvenating Java on the desktop.

Hotspot

Sun's JVM uses a technique called Just In Time compiling (JIT) to complete compilation at run-time, translating from byte code to native machine code. Sun calls its JIT implementation the “Hotspot”TM compiler. There's a trade-off between the time the JVM spends optimizing the translation, and the time you save because your code now runs faster. The JVM tries to reduce the work by only translating the tight loops or “hot spots” of code, not the whole program. Most benchmarks show that Java code runs as fast as optimized native code, once the program starts.

Continuing the discussion of setting up Java, here's the command that runs a Java program:

We are going to use a digital clock program as an example in the rest of the chapter. You can download the clock.java source code file from www.afu.com/jj6 or you can type in the code from the listings later in the chapter. Either way, make sure the files are in your work directory and “cd” to it, so it becomes your current working directory. After successfully compiling, you can run a program with the main code in a class called “clock” by typing:

When you compile and run the example program, a window containing a digital clock display appears, and the display keeps updated with the current time. The commands to compile and run are shown in Figure 2-1. The example uses a Mac.

Figure 2-1. Compiling and running clock.java

The javac command will create a file called “clock.class” containing the bytecode. If you create the same files on a windows system (or move the clock.class file from any system over to a windows system), you can execute it with the command “java clock”. You will see a window like Figure 2-2 appear, and keep time:

Figure 2-2. Running the same clock program on Windows

Download or type in, then compile and run clock.java now. Don't sweat the details about understanding individual lines of code; we will go over them in the following sections. It's time to say a few words about classes and objects.