import java.awt.Graphics;
class ABClass extends java.applet.Applet {
    public void init() {
        /* Initialize any variables, images, etc here.
        Any initialization that only needs to be done once should be
        included here because this method is called only once. */
    }
    public void start() {
        /* This method can also be used for initialization.
        However, the difference for this one is that it is used for
        components in your applet that need to be initialized more
        than once, or if the reader leaves the applet and then
         returns. This method can be called more than once. */
    }

    public void stop() {
       /* This life cycle method is the counterpart to start().
       Any code to suspend execution should be retained here. */
    }

    public void destroy() {
        /* This method is used to clean up the applet before it is
       finished. This method is called only once. */
    }
    public void paint(Graphics g) {
        /* Any code to draw, write, or color things on the
        applet pane belongs here */
    }
}

In the preceding pseudo-applet, each method is called by the system at a particular moment, under specific circumstances, or in a special order. Some of the methods can be called more than once depending on how the user engages the applet and the environment in which the applet is being run.

To review more closely the logistics of an applet, the fact that an applet is designed to run in the heterogeneous and possibly unsecured environment of the Internet has imposed several restrictions on it. This explanation highlights an applet in its strictest sense, pointing out potential differences with that of applications. Also, note that in certain situations, there are exceptions to the following restriction, even in applets. In some cases, these restrictions can be lowered depending on the type of Internet browser running the applet and its configuration.

Applets cannot read or write to the user's file system. This means that the applet cannot access anything locally or place anything locally either. For example, many Windows-based applications written in C utilize an initialization file (an .INI file) in 16-bit Windows or the Registry in 32-bit Windows to store information about the application and any user preferences. This is not possible in the current applet model and imposes a challenge to traditional programming techniques. This limited access can also include just checking to see if a file even exists on the user's system.

Applets cannot utilize native methods, load shared libraries, or run any programs that may be on the user's system. The major security concern here is that native methods and local shared libraries (such as DLLs) can facilitate a loophole in the Java security model described in the previous paragraph.

Applets cannot communicate with any server other than the one from which they originated. In some cases, an encrypted key can be used to verify a particular applet to a server, or a server accessed due to a configuration with the Internet browser, but access to any server on the Net cannot be assumed.

Overall, applets provide a different format for program execution and a very tight security model, which is necessary in the very open environment of the Internet.