Review of Java Applets

 Comparing ActiveX to Java Classes  




  In order to tell Java that this program is going to be an applet, all that you basically need to do is create a subclass of the Applet class. Everything that makes up an applet is inherited from the superclass java.applet.Applet. Included in this inheritance are the basic user interface, methods for accessing parameters from an HTML page, and several methods known as life-cycle methods that are called directly by the system you use to organize your program. Another method that is part of the java.awt.Component class (which would be a super-super-super class to the class containing your applet) is the method paint(), which is used to draw various things in your applet's pane. The following shows an example of what the structure of a typical applet might look like:

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.





Copyright Manjor Inc.