Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Take an in-depth look at the Java Reflection API

Learn about the new Java 1.1 tools for finding out information about classes

By Chuck Mcmanis, JavaWorld.com, 09/01/97

In last month's "Java In-Depth," I talked about introspection and ways in which a Java class with access to raw class data could look "inside" a class and figure out how the class was constructed. Further, I showed that with the addition of a class loader, those classes could be loaded into the running environment and executed. That example is a form of static introspection. This month I'll take a look at the Java Reflection API, which gives Java classes the ability to perform dynamic introspection: the ability to look inside classes that are already loaded.

The utility of introspection

One of Java's strengths is that it was designed with the assumption that the environment in which it was running would be changing dynamically. Classes are loaded dynamically, binding is done dynamically, and object instances are created dynamically on the fly when they are needed. What has not been very dynamic historically is the ability to manipulate "anonymous" classes. In this context, an anonymous class is one that is loaded or presented to a Java class at run time and whose type was previously unknown to the Java program.

Anonymous classes
Supporting anonymous classes is hard to explain and even harder to design for in a program. The challenge of supporting an anonymous class can be stated like this: "Write a program that, when given a Java object, can incorporate that object into its continuing operation." The general solution is rather difficult, but by constraining the problem, some specialized solutions can be created. There are two examples of specialized solutions to this class of problem in the 1.0 version of Java: Java applets and the command-line version of the Java interpreter.

Java applets are Java classes that are loaded by a running Java virtual machine in the context of a Web browser and invoked. These Java classes are anonymous because the run time does not know ahead of time the necessary information to invoke each individual class. However, the problem of invoking a particular class is solved using the Java class java.applet.Applet.

Common superclasses, like Applet, and Java interfaces, like AppletContext, address the problem of anonymous classes by creating a previously agreed upon contract. Specifically, a runtime environment supplier advertises that she can use any object that conforms to a specified interface, and the runtime environment consumer uses that specified interface in any object he intends to supply to the run time. In the case of applets, a well-specified interface exists in the form of a common superclass.

The downside of a common superclass solution, especially in the absence of multiple inheritance, is that the objects built to run in the environment cannot also be used in some other system unless that system implements the entire contract. In the case of the Applet interfaces, the hosting environment has to implement AppletContext. What this means for the applet solution is that the solution only works when you are loading applets. If you put an instance of a Hashtable object on your Web page and point your browser to it, it would fail to load because the applet system cannot operate outside its limited range.

 

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

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