The Hypertext Markup Language

The Hypertext Markup Language, or HTML as it is commonly known, is used to define a web page. When you define a web page as an HTML document, it is stored in a file with the extension .html. An HTML document consists of a number of elements, and each element is identified by tags. The document will begin with < html > and end with < /html >. These delimiters, < html > and < /html >, are tags, and each element in an HTML document will be enclosed between a similar pair of tags between angle brackets. All element tags are case-insensitive, so you can use uppercase or lowercase, or even a mixture of the two, but by convention they are capitalized so they stand out from the text. Here is an example of an HTML document consisting of a title and some other text:

< html >  

< head > 

< title > This is the blog of Java < /title > 

< /head > 

< body > You can put whatever text you like here. The body of a 
document can contain all kinds of other HTML elements, including 
< b > Java applets < /b >. Note how each element always begins 
with a start tag identifying the element, and ends with an end tag 
that is the same as the start tag but with a slash added. The pair 
of tags around ‘Java applets’ in the previous sentence will display 
the text as bold.

< /body >

< /html > 

There are two elements that can appear directly within the < html > element, a < head > element and a < body > element, as in the example above. The < head > element provides information about the document, and is not strictly part of it. The text enclosed by the < title > element tags that appears here within the < head > element will be displayed as the window title when the page is viewed.

Other element tags can appear within the < body > element, and they include tags for headings, lists, tables, links to other pages, and Java applets. There are some elements that do not require an end tag because they are considered to be empty. An example of this kind of element tag is < hr/ >, which specifies a horizontal rule, a line across the full width of the page. You can use the < hr/> tag to divide up a page and separate one type of element from another.

Executing an Applet

The Java compiler in the JDK will compile both applications and applets. However, java applet is not executed in the same way as an application. You must embed an applet in a web page before it can be run. You can then execute it either within a Java 2-enabled web browser, or by using the applet-viewer, a bare-bones browser provided as part of the JDK. It is a good idea to use the applet-viewer to run applets while you are learning. This ensures that if your applet doesn’t work, it is almost certainly your code that is the problem, rather than some problem in integration with the browser. If you have compiled an applet and included it in a web page stored as MyApplet.html in the current directory on your computer, you can execute it by entering the command:

appletviewer MyApplet.html

So how do you put an applet in a web page.

Executing a Java Application

To execute the bytecode program in the .class file with the Java interpreter in the JDK, you make the directory containing the .class file current and enter the command:

java -enableassertions MyProgram

Note that we use just the name MyProgram to identify the program, not the name of the file generated by the compiler, MyProgram.class. It is a common beginner’s mistake to use the latter by analogy with the compile operation. If you put a .class file extension on MyProgram, your program won’t execute, and you will get an error message:

Exception in thread “main” java.lang.NoClassDefFoundError: MyProgram/class

While the compiler expects to find the name of your source file, the java application interpreter expects the name of a class, which is MyProgram in this case, not the name of a file. The MyProgram.class file contains the MyProgram class. We will explain what a class is shortly. The -enableassertions option is necessary for JDK 5.0 programs that use assertions, and since you will be using assertions once you have learned about them it’s a good idea to get into the habit of always using this option. You can abbreviate the -enableassertions option to -ea if you wish. If you want to override an existing CLASSPATH definition, the option is the same as with the compiler. You can also abbreviate -classpath to -cp with the compiler or the Java interpreter. Here’s how the command would look:

java -ea -cp . MyProgram

To execute your program, the Java interpreter analyzes and then executes the bytecode instructions. The Java Virtual Machine is identical in all computer environments supporting Java, so you can be sure your program is completely portable. As we already said, your program will run just as well on a Unix Java implementation as it will on that for Microsoft Windows, Solaris, Linux, OS/2, or any other operating system that supports Java.

Compiling a Java Program

Java source code is always stored in files with the extension .java. Once you have created the source code for a program and saved it in a .java file, you need to process the source using a Java compiler. Using the compiler that comes with the JDK, you would make the directory that contains your Java source file the current directory, and then enter the following command:

javac MyProgram.java

Here, javac is the name of the Java compiler, and MyProgram.java is the name of the program source file. This command assumes that the current directory contains your source file. If it doesn’t, the compiler won’t be able to find your source file. It also assumes that the source file corresponds to the Java language as defined in the current version of the JDK. There is a command-line option, -source, that you can use to specify the Java language version, so for JDK 5.0, the command above to execute the compiler is equivalent to:

javac -source 5 MyProgram.java

Note that you can also use 1.5 as the value with the source command-line option, in which case you could write the command like this:

javac -source 1.5 MyProgram.java

In practice you can ignore the -source command-line option unless you are compiling a Java program that was written using an older version of the JDK. For example, to compile code written for JDK 1.4 you would write:

javac -source 1.4 oldSourceCode.java

Here’s a simple program you can try out the compiler on:

public class MyProgram {

public static void main(String[] args) {

System.out.println(“Rome wasn’t burned in a day!”);

              &nb}

}

This just outputs a line of text to the command line. As this is just to try out the compiler, I won’t explain how the program works at this point. Of course, you must type the code in exactly as shown and save the source file as MyProgram.java. If you have made any mistakes the compiler will issue error messages. If you need to override an existing definition of the CLASSPATH environment variable - perhaps because it has been set by a Java development system you have installed - the command would be:

javac -classpath . MyProgram.java

The value of CLASSPATH follows the -classpath specification and here it is just a period. This defines just the path to the current directory, whatever that happens to be. This means that the compiler looks for your source file or files in the current directory. If you forget to include the period, the compiler will not be able to find your source files in the current directory. If you include the -classpath . commandline option in any event, it will do no harm. Note that you should avoid storing your source files within the directory structure that was created for the JDK, as this can cause problems. Set up a separate directory of your own to hold the source code for a program and keep the code for each program in its own directory.

Assuming your program contains no errors, the compiler generates a bytecode program that is the equivalent of your source code. The compiler stores the bytecode program in a file with the same name as the source file, but with the extension .class. Java executable modules are always stored in a file with the extension .class. By default, the .class file will be stored in the same directory as the source file. The command-line options we have introduced here are by no means all the options you have available for the compiler.

You will be able to compile all of the examples in the blog just knowing about the options we have discussed. There is a comprehensive description of all the options within the documentation for the JDK. You can also specify the -help command-line option to get a summary of the standard options you can use. If you are using some other product to develop your Java programs, you will probably be using a much more user-friendly, graphical interface for compiling your programs that won’t involve entering commands such as that shown above. However, the file name extensions for your source file and the object file that results from it will be just the same.

Installing the JDK

You can obtain detailed instructions on how to install the JDK for your particular operating system from the Sun web site, so I won’t go into all the variations for different systems here. However, you should watch out for a few things that may not leap out from the pages of the installation documentation.

First of all, the JDK and the documentation are separate, and you install them separately. The JDK for Windows is available in two versions - as a web install where components are downloaded incrementally, and as a full download of an .exe file that you just execute to start installation. The documentation for the JDK consists of a large number of HTML files structured in a hierarchy that are distributed in a ZIP archive. You will find it easier to install the JDK first, followed by the documentation. If you install the JDK to drive C: under Windows, the jdk1.5.0 directory sometimes referred to as the root directory for Java.

In some contexts it is also referred to as the Java home directory. The actual root directory name may have the release version number appended, in which case the actual directory name will be of the form jdk1.5.0_n where n is a release number, so in the first maintenance release, it will be jdk1.5.0_01, for example.

The sample directory contains sample applications that use JNLP, which is the Java Network Launching Protocol that is used for executing applications or applets from a network server without the need for a browser or the need to download and install the code. You don’t need to worry about the contents of most of these directories, at least not when you get started, but you should add the path for the jdk1.5.0\bin directory to the paths defined in your PATH environment variable. That way you will be able to run the compiler and the interpreter from anywhere without having to specify the path to it. If you installed the JDK to C:, then you need to add the path C:\jdk1.5.0\bin. A word of warning - if you have previously installed a commercial Java development product, check that it has not modified your PATH environment variable to include the path to its own Java executables.

If it has, when you try to run the Java compiler or interpreter, you are likely to get the versions supplied with the commercial product rather that those that came with the JDK. One way to fix this is to remove the path or paths that cause the problem. If you don’t want to remove the paths that were inserted for the commercial product, you will have to use the full path specification when you want to run the compiler or interpreter from the JDK. The jre directory contains the Java Runtime facilities that are used when you execute a Java program. The classes in the Java libraries are stored in the jre\lib directory. They don’t appear individually though. They are all packaged up in the archive, rt.jar. Leave this alone. The Java Runtime takes care of retrieving what it needs from the archive when your program executes.

The CLASSPATH environment variable is a frequent source of problems and confusion to newcomers to Java. The current JDK does NOT require CLASSPATH to be defined, and if it has been defined by some other Java version or system, it is likely to cause problems. Commercial Java development systems and versions of the Java Development Kit prior to 1.2 may well define the CLASSPATH environment variable, so check to see whether CLASSPATH has been defined on your system. If it has and you no longer have whatever defined it installed, you should delete it. If you have to keep the CLASSPATH environment variable - maybe because you want to keep the system that defined it or you share the machine with someone who needs it - you will have to use a command-line option to define CLASSPATH temporarily whenever you compile or execute your Java code. This corresponds to C:\jdk1.5.0 if you installed the JDK to your C: drive. This will create a new subdirectory, docs, to the root directory, and install the documentation files in that. To look at the documentation, you just open the index.html file that is in the docs sub-directory.