Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

A look at inner classes

Reduce class clutter in your Java designs: Use inner classes

JavaWorld.com, 10/01/97

In my December 1996 column titled "Generically speaking," I discussed the difficulty of building a generic collection class in Java. Since that time two things have happened: Sun created inner classes to assist in the implementation of Java Beans; and Sun has proposed a basic collection class for Java. I like Sun's proposal, but I wish the company had included a way of doing type enforcement. For those of you not familiar with the term, type enforcement is a mechanism that ensures that objects placed into a collection are of the proper type. Currently, the collections use class Object as a generic reference which, if through a bug in your class, you store an unexpected type into the collection, will cause a class cast exception when you retrieve the stored reference from the collection. For an example of a class that provides type enforcement, see the class ContainerOrganizer in the Resources section below.

If you think that type enforcement in collections is a Good Thing, I encourage you to write Sun at collection-comments.

For this column I thought it would be useful to revisit the class we designed last December and replace that example's "mixin" classes with inner classes.

What are inner classes?

Inner classes are class files whose "name" is scoped to be inside another class. What do I mean by "scope"? The scope of a name defines when that name can be referenced by Java code. When two classes share the same package, they are said to have "package scope." Classes that are outside the containing package cannot refer to classes inside the package that are not declared as being public. Thus the names of the classes are scoped to the package.

Inner classes are scoped to the class used to declare them -- thus they are effectively "invisible" to the other classes in the same package. This lack of visibility to other classes in the package gives the programmer the opportunity to create a set of classes within a containing class without cluttering up the name space of classes in their package.

According to Sun's design documents, the Sun engineers felt that inner classes removed what had been a wart in the definition of Java. The wart was that a Java class could only be defined as a peer of other classes. This created an artificial level that applied only to class definitions. Inner classes primarily are a change to Java compilers that gives them a mechanism to eliminate this wart. To support backwards compatibility with existing virtual machines, the inner classes are actually compiled to regular class files, only the names are changed to prevent them from colliding with existing classes. For more information on this "exchange of warts," I refer you to the complete design document.

The changes that were made to the Java language that would allow the language to support inner classes consisted of changing the rules about where you could declare a class. If you have been programming in Java 1.0x, you know that you can declare multiple classes in a single source file (as long as only one of them is public) and that the declaration of the second and subsequent classes must follow the closing brace of the first class. That is now changed in 1.1: Now you can declare a class within another class. The following example will illustrate this more clearly. In Java 1.0 you had to declare two classes in a file sequentially as shown in the code below.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.