Previous Table of Contents Next


14.4.2. Inner Classes

While the bulk of the changes in Java 1.1 are additions to the core Java API, there has also been a major addition to the language itself. The language has been extended to allow class definitions to be nested within other classes, and even to be defined locally, within blocks of code. Altogether, there are four new types of classes that can be defined in Java 1.1; these four new types are sometimes loosely referred to as “inner classes.”

As we’ll see, inner classes are useful primarily for defining simple “helper” or “adaptor” classes that serve a very specific function at a particular place in a program, and are not intended to be general-purpose “top-level” classes. By using inner classes nested within other classes, you can place the definition of these special-purpose helper classes closer to where they are actually used in your programs. This makes your code clearer, and also prevents you from cluttering up the package namespace with small special purpose classes that are not of interest to programmers using your package. We’ll also see that inner classes are particularly useful in conjunction with the new AWT event model in Java 1.1.

One important feature of inner classes is that no changes to the Java Virtual Machine are required to support them. When a Java 1.1 compiler encounters an inner class, it transforms the Java 1.1 source code in a way that converts the nested class to a regular top-level class. Once that transformation has been performed, the code can be compiled just as it would have been in Java 1.0.

14.4.3. The New AWT Event Model

The Java 1.1 change that will probably affect Java programmers the most is the new event processing model adopted for the AWT windowing and graphical user interface (GUI) toolkit. If you created applets or GUIs with Java 1.0, you know that it was necessary to subclass GUI components in order to handle events. This model worked okay for simple programs, but proved increasingly awkward as programs became more complex. Furthermore, with the development of the JavaBeans API, the AWT package needed an event model that would allow AWT GUI components to serve as beans. For these reasons, Java 1.1 defines a new model for dispatching and handling events.

The new event handling model is essentially a “callback” model. When you create a GUI component, you tell it what method or methods it should invoke when a particular event occurs on it (e.g., when the user clicks on a button or selects an item from a list). This model is very easy to use in C and C++ because those languages allow you to manipulate method pointers—to specify a callback, all you need to do is pass a pointer to the appropriate function. In Java, however, methods are not data and cannot be manipulated in this way. Only objects can be passed like this in Java, so to define a Java callback, you must define a class that implements some particular interface. Then, you can pass an instance of that class to a GUI component as a way of specifying the callback. When the desired event occurs, the GUI component invokes the appropriate method of the object you have specified.

As you might imagine, this new event handling model can lead to the creation of many small helper classes. (Sometimes these helper classes are known as “adaptor classes” because they serve as the interface between the body of an application and the GUI for that application. They are the “adaptors” that allow the GUI to be “plugged in” to the application.) This proliferation of small classes could become quite a burden, were it not for the introduction of inner classes, which, as noted above, allows this kind of special-purpose class to be nested and defined exactly where it is needed within your program.

Despite the major AWT event-handling changes, Java 1.1 does retain backwards compatibility with the event-handling model of Java 1.0. It is an all-or-nothing type of backwards compatibility, however—the two models are so different from each other that it is not really possible to mix them within the same application.

14.4.4. Deprecated Features

Although you can use the old AWT event model in Java 1.1, it has been officially “deprecated,” and its use in new software is discouraged. When you compile code that uses the 1.0 event model, you’ll be made aware of this by the “deprecation warning” that the javac compiler issues. This warning notifies you that your code relies on methods or classes in the Java API that have been superseded by newer, preferred alternatives. If you compile using the -deprecation flag, javac provides a detailed warning about each use of a deprecated feature. You can simply ignore these warnings, but when time permits, the better approach is to update your code so that it no longer relies on deprecated features of the Java API. While it is not strictly true to say that deprecated features are “unsupported,” they will almost certainly receive far less support in practice than the features that replace them.

The reason that the compiler is able to issue deprecation warnings at all is the addition of a new @deprecated tag to the documentation-comment syntax of Java 1.1. As you may be aware, comments that begin with the /** character sequence are treated specially in Java, and are used by the javadoc tool to automatically generate online documentation for packages, classes, methods, and fields. Prior to Java 1.1, the compiler ignored the contents of documentation comments. In Java 1.1, however, it scans these comments for the @deprecated tag. If it is found, the compiler marks the class, interface, constructor, method, or field following the comment as deprecated, and issues a warning when the deprecated feature is used.

The old AWT event-handling model is not the only Java 1.0 feature that has been deprecated in Java 1.1; merely the one you are most likely to encounter first. A number of common AWT component methods have been renamed, to follow a more regular naming scheme that fits the JavaBeans naming conventions. These methods can be invoked by the old name or the new, but if you use the old name, you’ll be rewarded with a deprecation warning. Fortunately, in simple cases like this, it is trivial to write a script or program to mechanically convert from the old name to the new. Other areas of the Java API have been deprecated as well. You’ll notice that a few of the input and output stream classes in the java.io package have been deprecated and superseded by Reader and Writer stream classes, for example.


Previous Table of Contents Next