An Introduction to Java

This tutorial will get you started in the Java programming language. It is intended for individuals with prior programming experience who need an introduction to the Java programming environment.

Java is a programming language and a platform. Unlike languages like C or Pascal, which can be compiled for multiple operating systems and machines, Java programs only run on the Java platform. It just so happens that the Java platform has been implemented for a variety of systems which is how Java claims to be "write once - run anywhere".

The Java platform consists of a set of libraries and a Java Virtual Machine (JVM). Java code is compiled into the assembly language for the JVM. This assembly language is referred to as bytecode. Technically, it is not really assembly language -- it still requires all sorts of run-time linking by the JVM -- but the concept of machine formatted instructions is very similar.

The Java platform is distributed as the "Java Runtime Environment" (JRE) and the "Java Development Kit" (JDK). The JRE has all the libraries and executables needed to run the JVM. The JDK contains every thing the JRE has, plus the programs needed to compile, debug, and document a Java program. There are seperate JDK and JRE distributions for different platforms.

The JRE and JDK are available from Sun Microsystems. At the time this was written, the quickest way to the distributions follow:

• Click Product & APIs on the left side of the screen.
  
• Scroll down to the Complete Product List and the Java 2 Platform product family
  

You will see several versions of Java are available. Following is a description of the versions available at the time of writing. I am assuming that you will be programing in Java so I will only be discussing the JDK from here on out. If you just want to learn Java, I recommend getting the latest final release (currently 1.3).

Java 2 SDK, Standard Edition, v 1.3

The latest release of the Java 2 platform. This version has several API improvements, libraries, bug fixes, and other enhancements. The debugging architechure was revamped (making integration with existing tools difficult). It is faster than previous versions both in compiling and execution. Several extension packages have been incorporated in the core release (including a sound engine - which was largely written by a friend of mine). Software written for this version will not necessarily work with older JDKs. The byte code is the same, but API changes in commonly used classes will fail. Final releases for some platforms are not available at this time, so if you are distributing an application soon, it might be better to stick with 1.2.2.

Java 2 SDK, Standard Edition, v 1.2.2

This is the currently the working horse of the Java 2 platform. It has gone through several iterations and is mostly stable and with few serious bugs. It is the latest version of the first Java 2 platform release and has been available for all supported platforms for a while. Swing package names were changed which caused annoyance when moving from the previous version. The release also includes several API and library enhancements over 1.1.8

Java Development Kit(JDK) 1.1.8 (JDK1.1.8)

This is the final release for the Java platform (it became the Java 2 platform in the next version). The JVMs in most browsers support the Java platform, but not the Java 2 platform. If you want your users to be able to run applets in a browser without the use of a plug-in, you should use this version.

Java Plug-in

Web browsers do not seem to keep up with the latest Java release, so Sun provides plug-ins that let you run the applets using the latest versions. Note that details with the plug-ins do not work the same on all browsers and all systems. These differences make writing professional, web-based applications a nightmare.

Download one of the releases. Note that there is a source release available for some of the platforms. If you download this, you will exclude yourself from working on any open-source Java implementations. I wouldn't do it unless you have a pressing need to change the source or fix a bug. The remainder of this tutorial will assume that you are working with JDK1.3. Follow the instructions on Sun's site to install the JDK. If you are running on Windows, I recommend installing to "C:\jdk1.3". The rest of the instructions will make this assumption. If you are running on Unix, I will assume that you are smart enough to know where you want to install it and how to change the instructions I provide. You should also download the documentation. Unzip it into C:\jdk1.3.

The installation location contains the file src.jar. This contains most of the source code for the platform's libraries. The source can be very useful when you are trying to find out what a class is doing and how it interacts with your code (often much more useful than the documentation). Unjar the file with the following command:

C:\jdk1.3\bin\jar xvf src.jar

Take a look in the installation location. The following sub-folders are important right now:

bin

Contains all of the executables needed for development on the java platform. Of particular interest are java, javac, and jar.

demo

Source for programs that demonstrate features of the Java platform.

jre

These are the files for the runtime environment. In my experience, the runtime environment has been a little faster than the development environment.

src

This is the library source code you just unjarred.

docs

This contains the documentation you just downloaded and unzipped. I recommend opening C:\jdk1.3-old\docs\api\index.html and bookmarking it right now. You will be using this a lot!

At this point, I feel like it would be natural to explain how the tools in the bin directory work. I am going to skip ahead to, what I see, as the most important concept to understand when you are moving to the Java platform. I have seen development houses miss this for years. Understanding this will pave the way for an extremely easy transition into Java.

Packages

In Java, everything that you write will be in a class. In general, there is only one class per file and the class name must be the same as the filename. A class with the name "Foo" must be in a file named "Foo.java". This convention is enforced! If you have a class in a file with a name different than the class, the compiler will complain.

Every class is also defined in something called a package. Packages are a technique to give you some control at organizing your class files. Namespaces are unique between packages, so it also lets you name your classes with less fear that you will conflict with someone else. A class "Foo" in package "mypackage.stuff" would be referenced as "mypackage.stuff.Foo".

Packages are defined hierarchically. The swing libraries are in the package javax.swing and the sound libraries are in javax.sound. Don't let this heirarchy fool you though. Each package is distinct in of itself. The heirachy is only in the mind of the programmer. Java recognizes no special relationships between children or siblings of packages. It is best to think of them as namespaces that organize your code in a logical way. There is also a root package. A class "Foo" in in the root package would be referenced as just "Foo".

Just as classes must be defined in files with like names, packages are defined by directories with like names. The class "mypackage.stuff.Foo" will be in "somedir/mypackage/stuff/Foo.java" where "somedir" is a path representing the location of the root package. When Java is looking for the class "mypackage.stuff.Foo", it first looks for a directory called "mypackage" in "somedir", then "stuff" in "mypackage", then "Foo.class" in "stuff". Java knows to look in "somedir" by using something called a "classpath".

The classpath tells Java where to look for root packages. The classpath can have multiple elements and the elements are searched in reverse order. If the classpath is defined as "C:\mypackage\;C:\otherpackage\" and Java is looking for the class mypackage.stuff.Foo, it will first look for Arcs.class in C:\otherpackage\mypackage\stuff\Foo.class and then C:\mypackage\mypackage\stuff\Foo.class. Note that on Unix systems, each element of the classpath is separated by a colon (':') instead of a semi-colon (';'). The separator for a particular system is actually defined in Java as "File.pathSeparator".

The elements of a classpath can consist of directory locations and jar files. JAR is an abbreviation for Java Archiver (which is a slight change from the Unix tool tar - tape archiver). A jar file contains a list of class files in a directory structure. It is very similar to a zip file and can even be compressed. The root contents of a jar file are considered to be a package root. Jar files are a convenient way to distribute applications with large numbers of classes and packages. They can even be compressed to minimize the time spent downloading them if containing an applet (compression does increase the load time however). The "jar" program in the jdk bin directory can be used to create and decompress jar files.