An applet is different from an application in that it doesn't have its own
window (JFrame). Instead, it uses a portion of the browser's
window. As a result, it must extend a different class, JApplet.
The JApplet class contains a number of methods which the browser
uses to communicate with the applet. Overriding those methods is the
fundamental applet-writing activity. Of course, to write these methods you need
to know the purpose of each and when they are called.
When a browser encounters an APPLET tag it finds the name of the class to run from the CODE and CODEBASE attributes. It then loads that class file and instantiates an object by calling the default constructor (the one with no arguments). If the constructor takes an argument, the browser won't know what to pass it. Traditionally, the constructor for an applet is empty because the applet is not guaranteed to have its full "environment" until after the browser has finished calling the constructor. This means that loading images over the network, for instance, won't work.
Traditionally, the work of the constructor is done inside the
init() method which is inherited from JApplet. The
browser calls this method once and only once after calling the default
constructor. This is where code for setting up the applet should go, including
laying out the user interface components.
The browser calls start() after init() and
each time the user returns to the page containing the applet.
The browser calls stop() each time the user leaves the page
containing the applet. If the applet consumes significant resources (such as
running an animation), those processes should be suspended when the user leaves
the page. They can be restarted in the start() method which is
called each time the user returns to the page containing the applet.
If your applet does not use threads to do two or more things at once, it
probably doesn't need to use start() and stop().
destroy() so you have an opportunity to release any resources. At
the introductory level, destroy() is unlikely to be needed.Armed with this knowledge of the lifecycle, make the following changes to
HangmanUI:
javax.swing.JApplet.extends clause from
CloseableFrame to
JApplet. public void init(),
overriding the (empty) method in a superclass. Copy and paste all the
code in
the HangmanUI constructor into init(). 
The result will look very much like running the application.
How do you know which is which? The AppletViewer will have
"AppletViewer" in its titlebar, and an "Applet" menu,
(see
image on the right) and should say "Applet started" at the bottom.
If you're just going to run the applet on your local machine, you obviously haven't made enough of a change to be worth the effort. In the next steps we'll move it to a web site so it can be run from anywhere in the world.
Obviously, other applications may involve more work. If our application involved a menu, or file I/O, for instance, more work would be necessary -- or putting the application on the web may not even be appropriate or possible.