Applets are "mini applications" written in Java that can be embedded
in a web page or, in principle, other program. And in reality, the most common case is to embed
them in a web page. Writing an applet is largely similar to writing a normal application
(and with not much effort, you make most applets work as normal applications too). However,
there are also some differences to bear in mind:
- an applet is intrinsically GUI-based (whereas, for example, you could write a
command-line utility as a normal Java application);
- usually, applets have some quite severe security restrictions imposed upon them—
for example, they usually can't execute arbitrary native code,
access the local file system, query system properties or even make a network
connection to a host other than that from which they were downloaded; other actions
such as accessing the clipboard or playing audio may also be restricted depending on
the particular browser/environment;
- although not an absolute necessity, applets are usually expected to be
more conservative with resources than full-blown applications, and may, for
example, have severe heap size limitations imposed on them (and even if they don't, it's
generally polite behaviour not to eat hundreds of megabytes in a web page plugin).
If you essentially know what an applet is and just want to start writing one,
then you may want to skip straight ahead to the next section, which gives
a skeleton Java applet and discusses how to
build on it.
When to use applets?
The above points mean that applets are great for certain things and unsuitable (or
akward to implement) for other things. I personally think they're most at home
when you need an interactive part of a web page that involves some degree of logic
or moderately complex user interface. Writing your component as an applet gives you
the benefits of having a "full" object-oriented language, a moderately rich
user interface library in the form of Swing, and indeed pretty much
all of the standard Java platform (including things such as Javasound and
the Java concurrency library).
If your component is just, say, a simple animation, you may find that other tools
such as Flash are more appropriate. On the other hand, so long as you're prepared
to program it, you can do some quite
complex graphics and animation with Java applets— after all, you have the
whole Java2D framework at your disposal.
To give you a small taster of some simple applets, here are some that
I use on some of my web sites:
- French wordsearch
applets, which give an example of a combination of "moderate logic" (creating a random
wordsearch) combined with some simple animation (see the corresponding
- an applet
with printing support;
- a Spanish
sentence tutorial (scroll to the bottom of the page to see the applet), in which
some degree of logic is required— in this case, the applet must do things such
as calcualate verb forms and interpret what mistake the user has made in a sentence,
combined with a bit of interface (a simple drag-and-drop style in this case).
If you look on the web, you'll find plenty of other examples, ranging from
physics simulations to spectrum emulators to new feeds.
Notice a technique used by various of these applets and extremely usedful for
deployment in web sites, in which the same applet
is configured to behave differently on different pages. As you page through
the Spanish tutorial, for example, you'll see that each page practises some different
language feature. But in reality, the applet code is the same each time; the web page
contains parameters passed into the applet to indicate how it should behave. The same
is true of the wordsearches and crosswords: the particular words to use on that page
are passed into the applet as parameters.
When not to use applets?
In practice, Applets are unsuitable for more "heavywiehgt" applications: essentially
where an application needs to override one of the restrictions mentioned above. For example:
- where a program needs to have "free reign" in accessing local resources
or making network connections to arbitrary hosts;
- where the program is really an "entity in its own right" and it doesn't make
sense to embed it in a web page etc;
- where the program relies on non-standard libraries (JDBC connectors,
extensions such as the Java Media Framework etc) that may not be available
within a web page context.
Next: skeleton applet code
As mentioned, the next page introduces the JApplet class,
which is where some of the Applet "housekeeping" code lives. We present a skeleton applet, and
then discuss how to expand it.