Java Running Applets
Problem
You want to run an applet.
Solution
Write a class that extends java.applet.Applet; write some HTMLand point a
browser at it.
Make Versus
Ant
make is another build tool used in Unix and C/C++ development. make and Ant each
have advantages; I’ll try to stay neutral, although I admit I have been using make far
longer than I have Ant.
Makefiles are shorter. No contest. make has its own language instead of using XML, so
it can be a lot more terse. make runs faster; it’s written in C. However, Ant has the ability
to run many Java tasks at once—such as the built-in Java compiler, jar/war/tar/zip
files, and many more—to the extent that it may be more efficient to run several Java
compilations in one Ant process than to run the same compilations using make. That
is, once the JVM that is running Ant itself is up and running, it doesn’t take long at all
to run the Java compiler and run the compiled class. This is Java as it was meant to be!
Ant files can do more. The javac task in Ant, for example, automatically finds all the *.java
files in subdirectories. With make, a sub-make is normally required. And the include
directive for subdirectories differs between GNU make and BSD make.
Ant has special knowledge of CLASSPATH, making it easy to set a CLASSPATH in various
ways for compile time. See the CLASSPATH setting in Example 1-1. You may
have to duplicate this in other ways—shell scripts or batch files—for manually running
or testing your application.
Make is simpler to extend, but harder to do so portably. You can write a one-line make
rule for getting a CVS archive from a remote site, but you may run into incompatibilities
between GNU make, BSD make, etc. There is a built-in Ant task for getting an
archive from CVS using Ant; it was written as a Java source file instead of just a series
of command-line commands.
Make has been around much longer. There are millions (literally) more Makefiles than
Ant files. Non-Java developers have typically not heard of Ant; they almost all use
make. Almost all non-Java open source projects use make.
Make is easier to start with. Ant’s advantages make more sense on larger projects. Yet
of the two, only make has been used on the really large projects. For example, make is
used for telephone switch source code, which consists of hundreds of thousands of
source files containing tens or hundreds of millions of lines of source code. By contrast,
Tomcat 4 is about 340,000 lines of code, and the JBoss J2EE server about 560,000
lines. The use of Ant is growing steadily, particularly now that most of the widely used
Java IDEs (JBuilder, Eclipse, NetBeans, and others) have interfaces to Ant. Effectively
all Java open source projects use
Ant.
make is included with most Unix and Unix-like systems and shipped with many Windows
IDEs. Ant is not included with any operating system but is included with many
open source Java packages.
To sum up, although make and Ant are both good tools, new Java projects should use
Ant.
Explained
An applet is simply a Java class that extends java.applet.Applet, and in doing so
inherits the functionality it needs to be viewable inside a web page in a Java-enabled
web browser.* All that’s necessary is an HTMLpage referring to the applet. This
HTMLpage requires an applet tag with a minimum of three attributes, or modifiers:
the name of the applet itself and its onscreen width and height in screen dots or pixels.
This is not the place for me to teach you HTMLsyntax—there is some of that in
Recipe 18.1—but I’ll show my HTMLapplet template file. Many of the IDEs write a
page like this if you use their “build new applet” wizards:
<html> <head><title>A Demonstration</title></head> <body> <h1>My TEMPLATE Applet</h1> <applet code="CCC" width="200" height="200"> </applet> </body> </html>
You can probably intuit from this just about all you need to get started. For a little more detail, see Recipe 18.1. Once you’ve created this file (replacing the CCC with the fully qualified class name of your applet—e.g., code="com.foo.MyApplet") and placed it in the same directory as the class file, you need only tell a Java-enabled web browser to view the HTML page, and the applet should be included in it.
All right, so the applet appeared and it even almost worked. Make a change to the Java source and recompile. Click the browser’s Reload button. Chances are you’re still running the old version! Browsers aren’t very good at debugging applets. You can sometimes get around this by holding down the Shift key while you click Reload. But to be sure, use AppletViewer, a kind of mini-browser included in the JDK. You need to give it the HTMLfile, just like a regular browser. Sun’s AppletViewer (shown in Figure 1-9 under Windows) has an explicit Reload button that actually reloads the applet. And it has other features, such as debugging hooks, and other information displays. It also has a View ➝ Tag option that lets you resize the window until the applet looks best, and then you can copy and paste the tag—including the adjusted width and height attributes—into a longer HTML document.
The Mac OS X runtime includes both the standard AppletViewer from Sun and Apple’s own implementation (available as /Applications/Utilities/Java/Applet Launcher, shown in Figure 1-10), which is more colorful but slightly different. It has no Reload item in its menu; you close the Applet’s window and press the Launch button to reload. It also lets you load a new HTMLfile by typing in the URLfield (or pressing Open... and browsing), which is more efficient than closing and restarting the traditional AppletViewer when the HTMLfile changes or when you want to invoke a different file.
Neither the Sun version nor the Apple version is a full applet runtime; features such as jumping to a new document do not work. But they are very good tools for debugging applets. Learn to use the AppletViewer that comes with your JDK or IDE.
See Also
The bad news about applets is that they either can’t use features of current Java versions or they run into the dreaded browser-incompatibility issue. In Recipe 23.6, I show how to use the Java Plug-in to get around this. In Recipe 23.13, I talk about Java Web Start, a relatively new technique for distributing applications over the Web in a way similar to how applets are downloaded; with JWS, programs are downloaded using HTTP but stored as, and run as, regular applications on your system’s local disk.
No comments:
Post a Comment