Applet Basics | Core Java(TM) 2, Volume I--Fundamentals (7th Edition) (Core Series) (Core Series)

You use HTML (the hypertext markup language) to describe the layout of a web page. HTML is simply a vehicle to indicate elements of a hypertext page. For example, <title> indicates the title of the page, and any text that follows this tag becomes the title of the page. You indicate the end of the title with the </title> tag. (This is one of the general rules for tags: a slash followed by the name of the element indicates the end of the element.)

The basic idea of how to use applets in a web page is simple: the HTML page must tell the browser which applets to load and then where to put each applet on the web page. As you might expect, the tag needed to use an applet must tell the browser the following:

Where to get the class files;
How the applet is positioned on the web page (size, location, and so on).

The browser then retrieves the class files from the Internet (or from a directory on the user's machine) and automatically runs the applet, using an external Java runtime environment or its built-in Java virtual machine.

In addition to the applet itself, the web page can contain all the other HTML elements you have seen in use on web pages: multiple fonts, bulleted lists, graphics, links, and so on. Applets are just one part of the hypertext page. It is always worth keeping in mind that the Java programming language is not a tool for designing HTML pages; it is a tool for bringing them to life. This is not to say that the GUI design elements in a Java applet are not important, but that they must work with (and, in fact, are subservient to) the underlying HTML design of the web page.

NOTE

We do not cover general HTML tags; we assume that you know or are working with someone who knows the basics of HTML. Only a few special HTML tags are needed for Java applets. We do, of course, cover those later in this chapter. As for learning HTML, you can find dozens of HTML books at your local bookstore. One that covers what you need and that will not insult your intelligence is HTML and XHTML: The Definitive Guide by Chuck Musciano and Bill Kennedy from O'Reilly & Associates.

When applets were first developed, you had to use Sun's HotJava browser to view web pages that contained applets. Naturally, few users were willing to use a separate browser just to enjoy a new web feature. Java applets became really popular when Netscape included a Java virtual machine in its Navigator browser. Microsoft Internet Explorer soon followed suit. Unfortunately, two problems happened. Netscape didn't keep up with more modern versions of Java, and Microsoft vacillated between reluctantly supporting outdated Java versions and dropping Java support altogether.

To overcome this problem, Sun released a tool called the "Java Plug-in". Using the various extension mechanisms of Internet Explorer or Navigator, it seamlessly plugs in to both Netscape and Internet Explorer and allows both browsers to execute Java applets by using an external Java runtime environment that Sun supplies. By keeping the Plug-in up-to-date, you can always take advantage of the latest and greatest features of Java.

NOTE

To run the applets in this chapter in a browser, you need to install the current version of the Java Plug-in and make sure your browser is connected with the Plug-in. Go to http://java.sun.com/getjava for download and configuration information.

Admittedly, if you are designing web pages for a wide audience, it is probably unreasonable to ask the visitors to your web page to install the Java Plug-in, which is a fairly hefty (if one-time) download. Before turning to applets, you should check whether you can just use HTML forms, JavaScript, and animated GIF files to implement the client user interface. Then place the intelligence on the server, preferably with Java-based servlets and server pages.

On the other hand, if you roll out a very sophisticated Java program, you should ask yourself whether there is any benefit from using the web browser as a delivery vehicle. If not, then you can simply deliver Java applications that your users run on their local machines. You still have all the benefits of Java, such as platform independence, security management, and easy database and network access.

Of course, there are advantages to web deployment. For a user, it is often easier to locate an application on the Web than on the local file system. (This is particularly true for applications that aren't used every day.) For an administrator, it is easier to maintain and update an application on the web server than to push out bug fixes and improvements to lots of client desktops.

Thus, among the most successful Java programs are corporate intranet applications that interface with corporate information systems. For example, many companies have put expense reimbursement calculators, benefit tracking tools, schedule and vacation planners, purchase order requests, and so on, on their corporate intranet. These programs are relatively small, need to interface with databases, need more flexibility than web forms can provide, and need to be customized to the operations of a particular company. Applets and the Java Web Start mechanisms are excellent delivery technologies for these programs. Because the user population is constrained, it is less of a problem to manage the installation of the Java run time.

We start out with applets, both for the sake of tradition and because understanding applets gives you a head start with the Java Web Start technology.

A Simple Applet

For tradition's sake, let's write a NotHelloWorld program as an applet. Before we do that, we want to point out that, from a programming point of view, an applet isn't very strange. An applet is simply a Java class that extends the java.applet.Applet class. Note that although the java.applet package is not part of the AWT package, an applet is an AWT component, as the inheritance chain shown in Figure 10-1 illustrates. In this book, we will use Swing to implement applets. All of our applets will extend the JApplet class, the superclass for Swing applets. As you can see in Figure 10-1, JApplet is an immediate subclass of the ordinary Applet class.

Figure 10-1. Applet inheritance hierarchy

NOTE

If your applet contains Swing components, you must extend the JApplet class. Swing components inside a plain Applet don't paint correctly.

Example 10-1 shows the code for an applet version of "Not Hello World".

Notice how similar this is to the corresponding program from Chapter 7. However, because the applet lives inside a web page, there is no need to specify a method for exiting the applet.

Example 10-1. NotHelloWorldApplet.java

  1 ./*  2.   The following HTML tags are required to display this applet in a browser:  3.   <applet code="NotHelloWorldApplet.class" width="300" height="100">  4.   </applet>  5. */  6.  7. import javax.swing.*;  8.  9. public class NotHelloWorldApplet extends JApplet 10. { 11.    public void init() 12.    { 13.       JLabel label = new JLabel("Not a Hello, World applet", SwingConstants.CENTER); 14.       add(label); 15.    } 16. }

Applet Viewing

To execute the applet, you carry out two steps:

1.	Compile your Java source files into class files.
2.	Create an HTML file that tells the browser which class file to load first and how to size the applet.

It is customary (but not necessary) to give the HTML file the same name as that of the applet class inside. So, following this tradition, we call the file NotHelloWorldApplet.html. Here are the contents of the file:

 <applet code="NotHelloWorldApplet.class" width="300" height="300"> </applet>

Before you view the applet in a browser, it is a good idea to test it in the applet viewer program that is a part of the JDK. To use the applet viewer in our example, enter

 appletviewer NotHelloWorldApplet.html

at the command line. The command-line argument for the applet viewer program is the name of the HTML file, not the class file. Figure 10-2 shows the applet viewer displaying this applet.

Figure 10-2. Viewing an applet in the applet viewer

TIP

You can also run applets from inside your editor or integrated environment. In Emacs, select JDE -> Run Applet from the menu. In Eclipse, you select Run -> Run as -> Java Applet from the menu.

TIP

Here is a weird trick to avoid the additional HTML file. Add an applet tag as a comment inside the source file:

 /*   <applet code="MyApplet.class" width="300" height="300">   </applet> */ public class MyApplet extends JApplet . . .

Then run the applet viewer with the source file as its command-line argument:

 appletviewer NotHelloWorldApplet.java

We aren't recommending this as standard practice, but it can come in handy if you want to minimize the number of files that you need to worry about during testing.

The applet viewer is good for the first stage of testing, but at some point you need to run your applets in a browser to see them in the same way a user might use them. In particular, the applet viewer program shows you only the applet, not the surrounding HTML text. If an HTML file contains multiple applet tags, the applet viewer pops up multiple windows.

To properly view the applet, you need a Java 2-enabled browser. After installing and configuring the Java Plug-in, simply load the HTML file into the browser (see Figure 10-3). If the applet doesn't show up, your browser probably uses its built-in virtual machine, and you need to configure it to use the Java Plug-in instead.

Figure 10-3. Viewing an applet in a browser

TIP

If you make a change to your applet and recompile, you need to restart the browser so that it loads the new class files. Simply refreshing the HTML page will not load the new code. This is a hassle when you are debugging an applet. You can avoid the painful browser restart if you launch the Java console and issue the x command, which clears the classloader cache. Then you can reload the HTML page, and the new applet code is used. You can launch the Java console in Netscape and Mozilla from the menu. Under Windows, open the Java Plug-in console in the Windows control panel and request that the Java console be displayed.

NOTE

For older browsers (in particular, Netscape 4), you need to replace the applet tags with special object or embed tags in order to cause the browser to load the Plug-In. The page http://java.sun.com/j2se/5.0/docs/guide/plugin/developer_guide/html_converter.html describes this process and lets you download a tool that automates the web page conversion. With modern browsers, the conversion is no longer necessary.

Application Conversion to Applets

It is easy to convert a graphical Java application (that is, an application that uses the AWT and that you can start with the java program launcher) into an applet that you can embed in a web page. Essentially, all of the user interface code can stay the same.

Here are the specific steps for converting an application to an applet.

1.	Make an HTML page with the appropriate tag to load the applet code.
2.	Supply a subclass of the `JApplet` class. Make this class `public`. Otherwise, the applet cannot be loaded.
3.	Eliminate the `main` method in the application. Do not construct a frame window for the application. Your application will be displayed inside the browser.
4.	Move any initialization code from the frame window constructor to the `init` method of the applet. You don't need to explicitly construct the applet object the browser instantiates it for you and calls the `init` method.
5.	Remove the call to `setSize`; for applets, sizing is done with the `width` and `height` parameters in the HTML file.
6.	Remove the call to `setDefaultCloseOperation`. An applet cannot be closed; it terminates when the browser exits.
7.	If the application calls `setTitle`, eliminate the call to the method. Applets cannot have title bars. (You can, of course, title the web page itself, using the HTML `title` tag.)
8.	Don't call `setVisible(true)`. The applet is displayed automatically.

NOTE

On page 520, you will see how to implement a program that is both an applet and an application.

As an example of this transformation, we will change the calculator application from Chapter 9 into an applet. In Figure 10-4, you can see how it looks, sitting inside a web page.

Figure 10-4. A calculator applet

Example 10-2 shows the HTML page. Note that there is some text in addition to the applet tags.

Example 10-2. Calculator.html

 1. <html> 2.    <head><title>A Calculator</title></head> 3.    <body> 4.       <p>Here is a calculator, just in case you can't find yours.</p> 5.       <applet code="CalculatorApplet.class" width="180" height="180"> 6.       </applet> 7.    </body> 8. </html>

Example 10-3 is the code for the applet. We introduced a subclass of JApplet, placed the initialization code into the init method, and removed the calls to setTitle, setSize, setDefaultCloseOperation, and setVisible. The CalculatorPanel class is taken from Chapter 9, and its code is omitted.

Example 10-3. CalculatorApplet.java

  1. import java.awt.*;  2. import javax.swing.*;  3.  4. public class CalculatorApplet extends JApplet  5. {  6.    public void init()  7.    {  8.       CalculatorPanel panel = new CalculatorPanel();  9.       add(panel); 10.    } 11. }

 java.applet.Applet 1.0

void init()
is called when the applet is first loaded. Override this method and place all initialization code here.
void resize(int width, int height)
requests that the applet be resized. This would be a great method if it worked on web pages; unfortunately, it does not work in current browsers because it interferes with their page-layout mechanisms.

Life Cycle of an Applet

Four methods in the Applet class give you the framework on which you build any serious applet: init, start, stop, and destroy. What follows is a short description of these methods, occasions when these methods are called, and the code you should place into them.

init
This method is intended for whatever initialization is needed for your applet. It is called after the param tags inside the applet tag have been processed. Common actions in an applet include processing param values (see page 508) and adding user interface components.
Applets can have a default constructor, but it is customary to perform all initialization in the init method instead of the default constructor.
start
This method is automatically called after the browser calls the init method. It is also called whenever the user returns to the page containing the applet after having gone off to other pages. This means that the start method can be called repeatedly, unlike the init method. For this reason, put the code that you want executed only once in the init method, rather than in the start method. The start method is where you usually restart a thread for your applet, for example, to resume an animation. If your applet does nothing that needs to be suspended when the user leaves the current web page, you do not need to implement this method (or the stop method).
stop
This method is automatically called when the user moves off the page on which the applet sits. It can, therefore, be called repeatedly in the same applet. Its purpose is to give you a chance to stop a time-consuming activity from slowing the system when the user is not paying attention to the applet. You would implement this method to stop an animation or audio playback.
destroy
This method is only called when the browser shuts down normally. Because applets are meant to live on an HTML page, you should not normally leave resources behind after a user leaves the page that contains the applet. But if you do, then you can close down the resources by overriding the destroy method.

 java.applet.Applet 1.0

void start()
override this method for code that needs to be executed every time the user visits the browser page containing this applet. A typical action is to reactivate a thread.
void stop()
override this method for code that needs to be executed every time the user leaves the browser page containing this applet. A typical action is to deactivate a thread.
void destroy()
override this method for code that needs to be executed when the user exits the browser.

Security Basics

Because applets are designed to be loaded from a remote site and then executed locally, security becomes vital. If a user enables Java in the browser, the browser will download all the applet code on the web page and execute it immediately. The user never gets a chance to confirm or to stop individual applets from running. For this reason, applets (unlike applications) are restricted in what they can do. The applet security manager throws a SecurityException whenever an applet attempts to violate one of the access rules.

What can applets do on all platforms? They can show images and play sounds, get keystrokes and mouse clicks from the user, and send user input back to the host from which they were loaded. That is enough functionality to show facts and figures or to get user input for placing an order. The restricted execution environment for applets is often called the "sandbox." Applets playing in the "sandbox" cannot alter the user's system or spy on it. In this chapter, we look only at applets that run inside the sandbox.

In particular, when running in the sandbox,

Applets can never run any local executable program.
Applets cannot communicate with any host other than the server from which they were downloaded; that server is called the originating host. This rule is often called "applets can only phone home." The rule protects applet users from applets that might try to spy on intranet resources.
Applets cannot read from or write to the local computer's file system.
Applets cannot find out any information about the local computer, except for the Java version used, the name and version of the operating system, and the characters used to separate files (for instance, / or \), paths (such as : or ;), and lines (such as \n or \r\n). In particular, applets cannot find out the user's name, e-mail address, and so on.
All windows that an applet pops up carry a warning message.

All this is possible only because applets are executed by the Java virtual machine and not directly by the CPU on the user's computer. Because the virtual machine checks all critical instructions and program areas, a hostile (or poorly written) applet will almost certainly not be able to crash the computer, overwrite system memory, or change the privileges granted by the operating system.

These restrictions are too strong for some situations. For example, on a corporate intranet, you can certainly imagine an applet wanting to access local files. To allow for different levels of security under different situations, you can use signed applets. A signed applet carries with it a certificate that indicates the identity of the signer. Cryptographic techniques ensure that such a certificate cannot be forged. If you trust the signer, you can choose to give the applet additional rights. (We cover code signing in Volume 2.)

The point is that if you trust the signer of the applet, you can tell the browser to give the applet more privileges. You can, for example, give applets in your corporate intranet a higher level of trust than those from www.cracker.com. The configurable Java security model allows the continuum of privilege levels you need. You can give completely trusted applets the same privilege levels as local applications. Programs from vendors that are known to be somewhat flaky can be given access to some, but not all, privileges. Unknown applets can be restricted to the sandbox.

NOTE

Java Web Start applications (discussed later in this chapter) have a slightly more versatile sandbox. Some system resources can be accessed, provided the program user agrees.

To sum up, Java has three separate mechanisms for enforcing security:

Program code is interpreted by the Java virtual machine, not executed directly.
A security manager checks all sensitive operations in the Java runtime library.
Applets can be signed to identify their origin.

NOTE

In contrast, the security model of the ActiveX technology by Microsoft relies solely on the third option. If you want to run an ActiveX control at all, you must trust it completely. That model works fine when you deal with a small number of trusted suppliers, but it simply does not scale up to the World Wide Web. If you use Internet Explorer, you will see the ActiveX mechanism at work. You'll need to accept Sun's certificate to install the Java Plug-in on Internet Explorer. The certificate tells you that the code came from Sun. It doesn't tell you anything about the quality of the code. Once you accept the installation, the program runs without any further security checks.

Pop-Up Windows in Applets

An applet sits embedded in a web page, in a frame whose width is given by the width and height attributes in the applet tag. This can be quite limiting. Many programmers wonder whether they can have a pop-up window to make better use of the available space. It is indeed possible to create a pop-up frame. Here is a simple applet with a single button labeled Calculator. When you click on the button, a calculator pops up in a separate window.

The pop-up is easy to do. Simply use a JFrame, but don't call setDefaultCloseOperation.

 frame = new CalculatorFrame(); frame.setTitle("Calculator"); frame.setSize(200, 200);

When the user clicks the button, toggle the frame so that it is shown if it isn't visible and hidden if it is. When you click on the calculator button, the dialog box pops up and floats over the web page. When you click on the button again, the calculator goes away.

 JButton calcButton = new JButton("Calculator"); calcButton.addActionListener(new    ActionListener()    {    public void actionPerformed(ActionEvent evt)    {       frame.setVisible(!frame.isVisible());    } });

There is, however, an issue that you need to consider before you put this applet on your web page. To see how the calculator looks to a potential user, load the web page from a browser, not the applet viewer. The calculator will be surrounded by a border with a warning message (see Figure 10-5).

Figure 10-5. A window that pops up over a browser

In early browser versions, that message was very ominous: "Untrusted Java Applet Window". Every successive version of the JDK watered down the warning a bit "Unauthenticated Java Applet Window", or "Warning: Java Applet Window". Now it is simply "Java Applet Window".

This message is a security feature of all web browsers. The browser wants to make sure that your applet does not launch a window that the user might mistake for a local application. The fear is that an unsuspecting user could visit a web page, which automatically launches the applets on it, and mistakenly type in a password or credit card number, which the applet could send back to its host.

To avoid any possibility of shenanigans like this, all pop-up windows launched by an applet bear a warning label. You can configure the Java Plug-in to omit the warning message for pop-up windows that are spawned by signed applets.

Example 10-4 shows the code for the PopupCalculatorApplet class.

Example 10-4. PopupCalculatorApplet.java

  1. import java.awt.*;  2. import java.awt.event.*;  3. import javax.swing.*;  4.  5. public class PopupCalculatorApplet extends JApplet  6. {  7.    public void init()  8.    {  9.       // create a frame with a calculator panel 10. 11.       final JFrame frame = new JFrame(); 12.       frame.setTitle("Calculator"); 13.       frame.setSize(200, 200); 14.       frame.add(new CalculatorPanel()); 15. 16.       // add a button that pops up or hides the calculator 17. 18.       JButton calcButton = new JButton("Calculator"); 19.       add(calcButton); 20. 21.       calcButton.addActionListener(new 22.          ActionListener() 23.          { 24.             public void actionPerformed(ActionEvent event) 25.             { 26.                frame.setVisible(!frame.isVisible()); 27.             } 28.          }); 29.    } 30. }