Sams Teach Yourself Visual J++ 6 in 21 Days

Sams Teach Yourself Visual J++ 6 in 21 Days

by Rick Leinecker, Richard C. Leinecker
Sams Teach Yourself Visual J++ 6 is an easy-to-use tutorial that breaks down the tasks of learning Visual J++ into 21 focused lessons. Readers learn through clear explanations of concepts, structured step-by-step tasks, and abundant code samples. This book covers all aspects of using Visual J++ to build a wide range of Java applets and applications, ActiveX objects,


Sams Teach Yourself Visual J++ 6 is an easy-to-use tutorial that breaks down the tasks of learning Visual J++ into 21 focused lessons. Readers learn through clear explanations of concepts, structured step-by-step tasks, and abundant code samples. This book covers all aspects of using Visual J++ to build a wide range of Java applets and applications, ActiveX objects, COM/DCOM objects, and more.

Product Details

Publication date:
Sams Teach Yourself Series
Product dimensions:
7.39(w) x 9.07(h) x 1.47(d)

Read an Excerpt

Sams Teach Yourself Visual J++ 6 in 21 Days - CH 3 - Making Applets Live On the Web

[Figures are not included in this sample chapter]

Sams Teach Yourself Visual J++ 6 in 21 Days
- 3 -
Making Applets Live On the Web

Today, you'll learn how to make your Java applets live on a Web site. First, you'll learn about the HTML file and what you need to do to edit it. Next, you'll learn what the <APPLET> tag is and how to use it. Another thing you'll learn is how to get applets uploaded to your Web site.

Today's lesson is important for anyone writing applets for Web sites. Application developers who're writing programs that will run on standalone PCs can skip to Day 4's chapter, "Debugging Java Applets and Applications."

In this chapter, we'll cover these topics:

  • The <APPLET> tag

  • HTML applet attributes

  • Class files


  • Applet parameters

  • Uploading to a Web server

  • The Web server layout

For Web developers, this chapter contains skills that are essential for migrating Java applets from local development machines to live Web servers.

The <APPLET> Tag

The <APPLET> tag, used to embed Java applets in Web pages, is the mother of all nonstandard tags. Depending on the applet you are embedding, and to what extent you choose to customize that applet for your page, the <APPLET> tag you must construct can be relatively simple or exceptionally complex.

The <APPLET> tag, like other compound tags, is composed of several parts. However, only a few of these parts are required. Whether or not you must provide anything other than the bare minimum depends entirely on the applet you are configuring. Some applets make heavy use of all parts of the <APPLET> tag; others need only the required parts.

The following code gives a simplified look at the four main parts of the <APPLET> tag:

<APPLET attributes> applet-parameters alternet-HTML </APPLET> 


As with all tags, both standard and nonstandard, the applet tag begins with an opening tag. And like many other tags, the applet tag supports various attributes--information that is used to enhance the way the applet looks or acts when a browser runs it.

Attributes are keywords that tell browsers to do something special when they encounter a tag; in the case of the <APPLET> opening tag, this something is a bit more complex than with other tags. Although many opening tags consist of nothing more than a letter or two (<A>, <I>, <BR>, and so forth) and no attributes whatsoever, the <APPLET> tag is much more involved. Not only must you provide the initial part of the opening tag (<APPLET>), but you also must supply at least three attributes that together tell the browser the name of the applet and how much space the applet will take up when displayed:

<APPLET CODE="MyApplet" HEIGHT=100 WIDTH=200> 

In this example, an applet named MyApplet has been specified. The CODE attribute of the opening tag identifies the file containing the applet. The HEIGHT and WIDTH attributes of the opening tag, on the other hand, are used to tell the browser how much space in the page the applet requires. In this case, the applet takes up 100 pixels in height and 200 pixels in width.

Notice that the name of the applet file, MyApplet, is surrounded by quotation marks, but the height and width values aren't. This is because the name of an applet file might contain spaces (for example, Ticker Tape), whereas numeric values never will (that is, the number one hundred is always represented by 100, not 10 0, 1 00, or even 1 0 0). Surrounding the name of the applet file with quotation marks ensures that the browser knows exactly what to look for, even if spaces are included with the name. For example, if you left off the quotation marks on an applet file named Ticker Tape, the browser would see only the first word. In this case, the browser would attempt to find the applet file named Ticker and would come up empty-handed.

NOTE: Case matters! When supplying the name of an applet file, be sure to type the name exactly, matching each letter case for case. For example, if an applet is named MyApplet, you must specify that name exactly in the CODE attribute. If you specify myapplet instead, the browser won't be able to find the applet!

About the class Extension
Almost all applets are stored in files having a .class extension. This is a result of the compile process, the final step of which involves converting human-readable Java source code into machine-readable bytecode. When converted, the bytecode is stored in a file with the .class extension.
As a result, the MyApplet applet is really stored in a file named MyApplet.class. Although you're free to include the .class extension when specifying your applets, you don't have to. Java-aware browsers know to look for a file with that extension. You must, however, provide the extension if it's anything other than .class. Thus, the following opening applet tag is functionally equivalent to the one shown previously, although slightly more precise when it comes to the applet filename:

<APPLET CODE="MyApplet.class" HEIGHT=100 WIDTH=200>


At a bare minimum, all opening <APPLET> tags must contain the three attributes shown in the preceding examples: CODE, HEIGHT, and WIDTH. These are known as required attributes, as shown in Table 3.1, because you can't include applets in Web pages without them.


Attribute Description
CODE Specifies the name of the applet class file
HEIGHT Specifies the height of the applet in pixels
WIDTH Specifies the width of the applet in pixels

In addition to the three required attributes, you can use various optional attributes to control how an applet appears in your pages. You can include these optional attributes, listed in Table 3.2, anywhere within the opening tag. I recommend, however, that you specify optional attributes after the three required ones to increase the readability of your HTML source code (the exception to this rule is CODEBASE, which should come before the CODE attribute if you use it).

It's time to show you a complete example for using the <APPLET> tag. The following HTML code shows you what an <APPLET> tag looks like for the MyApplet program:

<APPLET CODE="MyApplet" HEIGHT=100 WIDTH=200 ALT="This is a cool applet" HSPACE=10 VSPACE=25> 


Attribute Description
ALIGN Specifies where your applet is placed on the page in respect to the text around it; it can be one of the following nine alignments: left, right, top, text top, middle, absmiddle, baseline, bottom, and absbottom. The most common alignments (left, top, and right) are shown in Figure 3.1.
ALT Specifies alternate text to be displayed by Java-savvy browsers that are incapable of executing the applet for whatever reason. Note that this text is seen only by Java-savvy browsers because it falls within the opening <APPLET> tag, which all non-Java browsers skip over. If you want to communicate with non-Java browsers, do so using alternate HTML. ALT helps not only those who are running browsers incapable of displaying Java, but also those who have turned the capability off because of limited horsepower. If you present a convincing argument, those users might be persuaded to turn the feature back on "just this once" to see your applet run.
CODEBASE Specifies the base URL for your applet. The applet itself must be located relative to this URL. If CODEBASE isn't specified, the applet is expected to reside in the same directory as the Web page itself. We'll talk more about CODEBASE later.
HSPACE Specifies the horizontal space surrounding your applets.
NAME Specifies the symbolic name of your applet, allowing other applets embedded in the same page to locate your applet by name. This attribute is used only when applets on a page communicate with one another, something most applets don't do.
VSPACE Specifies the vertical space surrounding your applet.

TIP: After you begin adding optional attributes to the mix, the opening tag can become quite difficult to read. To further increase the readability of your HTML source code, I recommend placing any optional attributes on their own line:

<APPLET CODE="MyApplet" HEIGHT=100 WIDTH=200     ALT="This is a cool applet"     HSPACE=10     VSPACE=25>

The most common alignments: left, top, and right.

The browser doesn't care how the tag appears, as long as it begins with < and ends with >. As a result, you can format your opening tag in any way you want.


Under normal circumstances, the browser expects to find the applet file inside the same directory as the Web page itself. In this case, you must ensure that the applet file and Web page in which it is embedded share the same directory.

However, keeping the applet and the Web page in the same directory isn't always possible. What if the applet you want to embed in your page resides halfway around the world? In this case, it's physically impossible for your Web page and the applet to reside in the same directory. Figure 3.2 shows a picture of a hypothetical server that has three HTML pages. Each of these HTML pages uses two of the three applets that are stored in the Html/Applets directory.

FIGURE 3.2 Three HTML pages, each of which uses two of the three applets located in the Html/Applets directory.

And what if you want a bunch of different pages on your Web site to use the same applet? What a profound waste of time and Web server space it would be to have to upload a copy of the applet into every directory containing a Web page that used it. A better idea would be to have the applet reside in a central location on your server, where all pages can get to it. But how?

Fortunately, the optional CODEBASE tag does just that. It allows you to specify a URL that points to the directory containing your applet. When a Java-savvy browser encounters the CODEBASE attribute, it automatically knows to look for the applet in whatever directory that attribute points to. The URL you supply for CODEBASE can point to a directory on your server, or one on any other server on the Web:

<APPLET CODEBASE=""     CODE="MyApplet" HEIGHT=100 WIDTH=200> 

In this example, browsers won't look for the MyApplet applet inside the same directory as the Web page containing this <APPLET> tag. Instead, browsers expect the applet to be located on the Infinite Vision Technologies server, inside the applets directory.

The CODEBASE tag is particularly helpful when a number of pages on your site use the same applet. Rather than having multiple copies of the same applet scattered all around your server, you can place a single copy of the applet in one directory and specify the appropriate CODEBASE attribute in all pages. Not only does this take the headache out of creating these pages, because you no longer have to upload a copy of the applet for every page that uses it, but it also makes upgrading the applet a cinch--simply upgrade the single applet and you're done.

The URL you supply for CODEBASE can be either relative or absolute.

Applet Parameters

The second major part of the <APPLET> tag, applet parameters, is where you can really customize an applet. To make an applet look or act as you want it to, you use a special <PARAM> tag that has two of its own attributes: NAME and VALUE. Although not all applets are customizable, those that are allow you to supply information using one or more <PARAM> tags according to the following format:

<PARAM NAME="parameter name" VALUE="parameter value"> 

For example, an applet might allow you to provide a sound track that will play in the background when the applet is running. To tell the applet the name of the sound file to use and where that file is located, you could supply the following <PARAM> tag:

<PARAM NAME="sndTrack" VALUE="audio/rock/"> 

In this example, the name of the parameter is sndTrack. The value associated with this parameter, audio/rock/, is a relative URL leading to a sound file. Some applets might also accept an absolute URL for this parameter:

<PARAM NAME="sndTrack" VALUE=""> 

Because the author of an applet must write the programming code that allows the applet to deal with parameters, each applet is unique in the parameters it accepts. For example, another applet might also allow you to specify a sound track. However, depending on how it was written, it might not understand URLs at all. In this case, the applet might insist that the sound file reside in the same directory as the applet itself, meaning that you supply only a filename:

<PARAM NAME="music" VALUE=""> 

Here, the applet just looks for the sound file named, expecting to find it in the same directory in which the applet itself resides. Not only that, but the parameter name isn't sndTrack. Because the programmer decides which features you can customize, as well as the parameter names that correspond to these features, you'll find various names used for the same thing. Whereas this applet uses music as the parameter name corresponding to the file with a background sound track, others might use the name background, back music, sound_Track, sound, or just about anything else a programmer can think of.

Applets usually play sounds that are stored in the .au format. That's why each of the sound files specified here has the .au extension.

Good, Solid Values

Different applets might support any number of different parameters. It's not unusual, for example, to come across applets that support several different parameters, giving you great flexibility when it comes to configuring them. To supply more than one parameter, all you have to do is enter the parameters one after another.

A Marquee applet, for example, allows you to customize the text that scrolls across the screen. You can specify the font, style, and point size the text should appear in. All you have to do is provide a parameter tag for each:

<PARAM NAME="font_face" VALUE="Helvetica"> <PARAM NAME="font_size" VALUE=24> <PARAM NAME="font_italic" VALUE="yes"> <PARAM NAME="font_bold" VALUE="no"> <PARAM NAME="marquee" VALUE="The text you are reading will scroll across the screen"> 

You can customize the preceding applet in various ways, although you don't necessarily have to supply a parameter for each. Many applets supply a default if you don't bother to supply a parameter yourself. If, for example, you don't supply any information about the font, Marquee might use TimesRoman by default. Of course, it's up to the programmer whether an applet provides a default. Some applets force you to supply parameters; others are written to fall back on default values if you leave parameters out.

As the developer of Visual J++ programs, you must decide which parameters are and are not required. You'll be the one to determine which default parameters will be acceptable for a program's operation.

Just as with opening <APPLET> tag attributes, any parameter value that contains a space character (or many spaces) must be surrounded by quotation marks. Of course, when parameters require numeric values, you don't need to use quotation marks at all.

Multiple Values

Some applets don't stop at just one value being associated with a given parameter name. In many cases, you can supply several values at once. When this is possible, each value must be separated from the others so as not to confuse the applet. Typically, the | character is used to separate the values:

<PARAM NAME="sounds" VALUE="||"> 

In this case, the applet receives three sound files as one parameter. Not all applets accept multiple parameters, of course, but those that do insist that you separate each with a special character. Although the | character is the most common, it's up to the developer of the applet to decide which character you must supply. As a result, don't be surprised to find commas, colons, semicolons, and even spaces used to separate multiple values:

<PARAM NAME="sounds" VALUE=",,"> <PARAM NAME="images" VALUE="shark.gif:pig.gif:tiger.gif"> <PARAM NAME="speeds" VALUE="100 355 23 0 535"> 

Alternate HTML

Following any parameter tags that you might use, but before the closing </APPLET> tag, there is a special area where you can supply what's known as alternate HTML. Here, you can enter any amount of HTML code you want; such code will be displayed only by non-Java browsers.

Although applets completely ignore alternate HTML, it's an important part of the <APPLET> tag nonetheless. Alternate HTML gives you an opportunity to create Web pages that are useful to users who view your pages regardless of the browser they happen to use. If you don't supply alternate HTML for non-Java browsers, you run the risk of alienating these users.

Although a carriage return between the last <PARAM> tag and the alternate HTML isn't necessary, it makes the code easier to read.

It's always a good idea to provide alternate HTML code for your applets whenever possible. Of course, there are some things applets do that you can't mimic with standard HTML (such as playing music). However, whenever it's possible to provide alternate HTML code that approximates an applet's visual appearance, you should do it so that users of both non-Java and Java powered browsers will benefit from your site.

The Closing Applet Tag

The fourth and final part of the <APPLET> tag brings the entire tag to a close. To properly form an <APPLET> tag, you must balance the opening tag with a closing </APPLET> tag. When the browser sees </APPLET>, it knows there is no more to the applet.

Although many applets are quite easy to use for users, others are extremely complex. The more parameters the applet expects, the harder it will be for the Web designer to use. The only way users know how to construct an appropriate <APPLET> tag for a given applet is to read the information that came with the applet. Be sure to include good documentation with your applets.

Making Applets Live

After you've created an applet, the chances are pretty good that you'll want to make it available to the entire Web population. To do this, you must upload the various files that make up the applet to a Web site and test them, to make sure that nothing breaks in the process.

To upload applets to a Web site, you must have the authority and the tools (such as an ftp tool) to do so. If the site you want to add the applet to is maintained by someone other than yourself, you'll have to obtain permission and perhaps even get the access passwords if you plan to upload the materials yourself. If you don't already have such authority, you can give the applet and the various files it uses to someone who will eventually perform the upload.

Obtaining WS_FTP

My preference in tools for doing the file uploads is WS_FTP. It's a great FTP tool that you can download from a Web site. The version that's downloadable is a trial version. If you decide to continue using it, you're expected to buy the full version.

To get a copy of WS_FTP, go to the Ipswitch Web site at ipswitch/Default.htm. Besides getting the trial version, you'll be able to check out Ipswitch's entire line of products.

For the remainder of this chapter, the FTP program we'll use is WS_FTP. Before going any further, you might want to download the program and install it on your system.

Creating the Web Server Directory Layout

If this is the first time Java is being used at a site, it might be a good idea to create a directory structure that will contain the Java classes and other associated files such as audio and graphics files. This is pretty straightforward and will be similar to how the directory structure is set up on your local drive.

Make sure that you know in which directory the initial HTML file will be located. Many services require an index HTML file in a directory, and Web browsers that hit the site will automatically load this particular file. If your service has this requirement, you will probably want to place your Java files in this directory.

Connecting to the Server

If you have permission to upload files to a site on the Web, you're ready to get started.

After WS_FTP32 is installed, run it. The Session Properties dialog box, shown in Figure 3.3, will appear on top of the main program window.

In this dialog box, you'll enter information about the destination server, including its name (or IP address), your login name, and your password. If you have the Save Password and Auto Save Config check boxes selected, the information will be saved and you can log in by simply selecting the server from a list.

FIGURE 3.3 The first thing you see when you run WS_FTP is the Session Properties dialog box.

Fill in the Profile Name, Host Name, User ID, and Password fields. It's a good idea to make the Profile Name and Host Name the same to avoid ambiguity. With the information correctly entered, click the OK button and the program will try to log on to the server.

The left list box of WS_FTP's main window contains a listing of the current directory, even when you're not logged on to a server. When logged in, you'll see a directory listing in the list box on the right half of the screen, as shown in Figure 3.4. This shows only the names of the files and directories, not file and directory details. To get a listing of full file and directory information, click DirInfo in the right column of buttons.

FIGURE 3.4 The right list box contains a directory listing of the server to which you logged on.

You'll have to know how to find your directory on the server. Many ISPs have a directory structure that will make it hard to find your directory. Make sure that you have the documentation for your account. Although it might be cryptic (as is usually the case), it'll be your best bet of finding the directory. Other ISPs are more understanding and drop you right into your directory after you log on.

These are the steps for connecting to a server:

1. Run WS_FTP (the Session Profile dialog box will appear).

2. Enter information about the server such as the server name (or IP address), your login name, and your password.

3. Click the OK button and wait for WS_FTP to connect to the server.

4. In the list box on the left side of the WS_FTP window, navigate to the local directory you want to transfer from.

5. In the list box on the right side of the WS_FTP window, navigate to the server directory you want to transfer to.

6. Highlight the files you want to transfer and click the -> button.

Uploading the Applet

After you're connected, you can upload the files. I'll use a HelloWorld applet as an example. You must upload HelloWorld.class and HelloWorld.html. Not all three of these files (the HelloWorld.html, HelloWorld.class, and files) are necessary to run the Java program--only HelloWorld.class is required. You can upload if you want to offer the source code for download. Our example here will assume that you're uploading the .java source code so that users can download it.

The HelloWorld.html file is the HTML file that J++ created with some additional lines so that users can download the source code. Later in the chapter, we'll talk about incorporating this code into another HTML file, but for simplicity you'll use it as it was created and have your main HTML file upload HelloWorld.html.

Begin by navigating the left list box so that it shows all three HelloWorld files. Highlight them as shown in Figure 3.5 and then click the -> button.

The files will be uploaded to the server. Because the files are short and most modem connections are pretty fast, you won't see much more than a blink as the upload progress box appears during the upload. For longer files, the upload progress box will stay visible long enough for you to see it.

FIGURE 3.5 Highlight the files you want to upload and click the -> button.

CAUTION: Most FTP client programs, such as WS_FTP, automatically detect the type of file you're uploading. For FTP uploads, a distinction is usually required between binary and text files. When a program automatically detects the file type, you don't have to worry about it; the correct settings will be used for the transfer.
But some FTP client programs might not have an automatic detection feature. If this is the case, you'll have to specify text for HTML files, and binary for .class files.

Editing the HTML File

Editing the HTML file is an easy way to change the position at which your applet appears. You can center the applet, justify it on the left side of the browser screen, or justify it on the right side of the browser screen. Many of the applets created in this book will have parameters that reside in the HTML file. Changing them will alter the behavior of the applet.

After the three HelloWorld files are on the server in the correct directory, the main HTML file must be edited so that users have the chance to bring up your applet. As mentioned earlier, the main HTML file on your Web server will probably have a special name such as index.html. There's a difference between writing an applet and testing it on a local machine, and uploading to a Web server and testing on the server. Details such as what the name of the default (main) HTML page is are important.

For now, you'll have the main HTML file bring up HelloWorld.html. Open your main HTML file in a text editor. Add the following line:

<h3><p>Run <a href=HelloWorld.html> <i>HelloWorld</a></h3><p> 

A new line will appear when your browser opens the HTML at your site, as shown in Figure 3.6.

FIGURE 3.6 The line that was added to the HTML file causes Run HelloWorld to show in the browser.

When you click on the HTML line, you'll see the HelloWorld applet run in your browser. The source code is available for viewing with a line at the bottom labeled "The source," as shown in Figure 3.7. All HTML files created by J++ make the source code available.

Offering Your Source Code for Download
Most people who want to take a look at your source code don't want to look at it from within a browser. They usually want to download it and look at it on their computers. For this reason, it's a good idea to include an archived version of the source code. The best way to do this is to zip the source code into a separate file. You can then add another line that offers zipped source code for downloading.
Zip the source code to a file named You'll need the latest version of WinZip that supports long filenames. It can be found at

By the way, WinZip can be downloaded and used free of charge for a limited time. If you use it after 30 days, you need to register it.

Add the following line to your HelloWorld.html file, and the archived source code will be available for downloading:

<a>The source zipped.</a>


Now that you know how to make the changes in the HTML file for the HelloWorld applet, it's time to take a look at the complete file. Listing 3.1 has the HTML source code for the HelloWorld applet.


1   <HTML> 2   <HEAD> 3   <TITLE>HelloWorld Test HTML Page</TITLE> 4   </HEAD> 5   <BODY> 6       <applet 7           code=HelloWorld.class 8           name=HelloWorld 9           width=320 10          height=200 > 11          <param name=label value="Hello Visual J++ World."> 12          <param name=background value="008080"> 13          <param name=foreground value="FFFFFF"> 14      </applet> 15 16  <hr> 17  <a href="">The source.</a> 18  <a href="">The source zipped.</a> 19 20  </BODY>
21  </HTML> 

FIGURE 3.7 Your applet runs from inside of your browser, and the source code is available for viewing.

1. Connect to your server with an FTP program, such as WS_FTP32.
2. Upload HTML, Java, and Class files.
3. Edit the main HTML file by adding this:
<h3><p>Run <a href=HelloWorld.html>     <i>HelloWorld</a></h3><p>

4. Test the file with your browser.


Uploading your applets to a Web server is an important part of the development process. It's one you need to be familiar with so that you can do it without a lot of aggravation.

Editing your HTML files is important too. The appearance of your Java program relies on your ability to edit the HTML file and correctly set the applet parameters.

A good tool to use for uploading files is WS_FTP. A trial version can be downloaded and used free of charge for a limited time.


Q How do you indicate that a Java applet is to be embedded into a Web page?
A You use the <APPLET> tag in the HTML file. When a Java-aware browser sees the <APPLET> tag, it knows that anything that follows is part of a Java applet's attri- butes and its parameters.

Q What attributes are required in an <APPLET> tag?
A Three tags are required in an <APPLET> tag: CODE, HEIGHT, and WIDTH. CODE specifies the name of the applet class file. HEIGHT specifies the height of the applet window in pixels. WIDTH specifies the width of the applet window in pixels.

Q What is alternate HTML and why should you use it?
A Following any parameter tags you might use, yet before the closing </APPLET> tag, there is a special area where you can supply what's known as alternate HTML. Here, you can enter any amount of HTML code you want; such code will be displayed only by non-Java browsers.
Although applets completely ignore alternate HTML, it's an important part of the <APPLET> tag nonetheless. Alternate HTML gives you an opportunity to create Web pages that are useful to Web surfers regardless of the browser they happen to use. If you don't supply alternate HTML for non-Java browsers, you run the risk of alienating these users.

Q What information do you need for an FTP program so that you can connect to a Web site?
A The first thing you need to do is to make sure that you have a valid user account. This gives you permission to upload files to the Web server. For a program such as WS_FTP, you'll need to provide a username, a password, and the FTP server name (or IP address). This is the minimum information you'll need in order to connect to an FTP site. There might be additional required information if you must go through a proxy server to get to your space on the Web server. (Your site administrator can give you the information you need for connecting through a proxy server.)

Q Why would you want to make your Java source code available for download?
Many Visual J++ and Java programmers enjoy fostering an attitude of sharing with other programmers. Practically every Visual J++ programmer has at one point relied on source code found on the Web to learn how to do something for a project.

Q Why do you have to use FTP to upload files to the Web?
A You can't use HTTP because it's a one-way transfer. Users can only get files using HTTP. To send files to a server, you must use a trusted protocol such as FTP that requires a login name and password. Other options include using programs such as PC Anywhere.

Review Exercises

1. Now that you know how to send your applets to the Web, create some and make them available to the public through your Web site.

2. Create three applets that simply show some distinct text onscreen. Upload them to your Web server into a directory named Applets. Create three HTML pages. Have each of the HTML pages load in two of the three applets. Make sure that they find the applets by specifying the CODEBASE.

Meet the Author

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >