HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

One of the salient aspects of the Java language is the control it gives to developers for dynamically generating and reusing code. This allows the language to offer Java programmers the ability to write code in which the actual behavior is determined at runtime. Of the eleven buzzwords used to define Java, this article is going to focus on the dynamic nature of the Java programming language.

Java achieves its 'dynamism' through the use of its ClassLoader and two core APIs: Reflection and Introspection. We will begin this article with an introduction to these APIs and their roles in Java-based software development. The APIs are compared in the light of Bean-based component introspection and user-defined component reflection. This is followed by brief descriptions of each of the APIs. We will then walk the reader through a series of examples that illustrate the development of some programming utilities that may be used by readers in Java application development. It is assumed that readers have some familiarity with the JDK 1.1.x APIs. We will not attempt to cover the APIs in detail.

This article is the first in a series of two. A subsequent article will lead the readers through the development of a new category of dynamically generated adapters called Dynamic Adapters. This article concludes with a very brief introduction to the Adapter design pattern and Dynamic Adapters.

The Role of Reflection and Introspection in Java Development
Reflection and introspection are programming facilities in the Java programming language that allow an object to discover information about itself and other objects at runtime. Webster's dictionary defines reflection as "the act of giving back or showing an image of." Reflection in Java allows the developer to create objects that can:

  • Construct new class instances and new arrays
  • Access and modify fields of objects and classes
  • Invoke methods on objects and classes
  • Access and modify the elements of arrays

So, how is that different from regular object-oriented programming? Objects defined in other object-oriented programming languages can accomplish any of the above. However, in Java, the use of the Reflection API allows an object to do the above on another object (or on itself) without knowing at compile time what the object/class being acted upon looks like. The state and behavior of the object/class can be determined at runtime. Figure 1 illustrates the role of reflection in Java programming.

Figure 1
Figure 1:

Webster's dictionary defines introspection as "observation or examination of one's own state." In Java, introspection is used in the context of JavaBeans, which define Java's component model. Introspection is used to allow a Bean to discover the properties, methods and events of another Bean at runtime. This enables developers to design and build their own Beans without knowing about the internals of another Bean.

Introspection is used by visual builder tools to introspect on Beans; i.e., to determine what properties are exposed by the Bean, what public methods it provides and what events it can generate. However, Introspection is a facility that is available to all Java classes, not just JavaBeans. Figure 2 illustrates the role of introspection in Java programming.

Figure 2
Figure 2:

Introspection Uses Reflection
Reflection and introspection are very closely related. Reflection is a low-level facility that allows the code to examine the internals of any class or object at runtime. Introspection builds on this facility and provides a more convenient interface for examining Beans. In fact, the relationship between reflection and introspection is very similar to the relationship between JavaBeans and other Java classes. JavaBeans are simply normal Java objects with certain design patterns enforced in their nomenclature. Introspection assumes these design patterns on the object that it is inspecting and uses low-level reflection to examine the object's internals.

The Reflection API
The Reflection API became a part of core Java with release 1.1 of the JDK. The API is defined across the following:

  • The new methods added to the java.lang.Class class in JDK 1.1
  • The java.lang.reflect package defined in JDK1.1

The class java.lang.Class contains methods that return instances of classes/interfaces defined in the java.lang.reflect package. A detailed description of the API is beyond the scope of this article and can be found in any standard Java text. However, the classes that comprise the Reflection API are listed in Table 1.

Table 1

The Introspection API
The Introspection API consists of several classes in the java.beans package. Again, a detailed description of the API is beyond the scope of this article and can be found in any standard Java text. The main classes in the Introspection API are listed in Table 2.

Table 2

The Costs of Usage
Reflection and Introspection are powerful tools that contribute to the flexibility provided by the Java language. However, these APIs should be used only as needed and after taking into account the costs associated with their usage:

  • Reflection and Introspection method calls have a substantial performance overhead.
  • Using reflection makes the code much more complex and harder to understand than using direct method calls.
  • Errors in method invocation are discovered at runtime instead of being caught by the compiler.
  • The code becomes type-unsafe.
The Reflection and Introspection APIs should be used only when other forms of object-oriented programming are not appropriate.

The following examples demonstrate the use of Reflection and Introspection to develop some useful Java utilities.

Cookie Factory
Our first example illustrates the use of Reflection to build a utility that allows us to instantiate objects of types derived from a "Cookie" interface. The actual type of the object instantiated is determined by a String parameter, which contains the name of the actual class. The code for the example is shown in Listings 1and 2.

Listing 1 defines the Cookie interface and the derived classes. The Cookie interface is simply a marker interface which is implemented by the classes FortuneCookie and MisFortuneCookie. Both these classes define a single static method which prints out a string and returns a new instance of the respective class.

Listing 2 shows the CookieFactory class which is capable of producing objects derived from the "Cookie" interface. It defines a single method createCookie that takes a String parameter, className. The Class corresponding to this name is obtained from the Class class by calling

c = Class.forName(className);

Once we have the class, we need to obtain the method to be called on it. The name of the method is "newCookie." In this example, we are assuming that the name of the method is available at this point. The parameter types for the method are filled in an array of type Class and this is used to get the actual Method object as follows:

method = c.getMethod("newCookie", pTypes);

Once the Method object is available, the static method is invoked on the class after constructing an array of Objects that contains the actual parameter instances:

cookie = (Cookie)(method.invoke(c, params));

A simple tester for the class is provided in the main() method. This first constructs the CookieFactory and then creates instances of the FortuneCookie and MisFortuneCookie class. The output from the program is shown in Figure 3.

Figure 3
Figure 3:

An X-Ray Class
Our second example illustrates the use of reflection to build a utility that allows us to view all the methods, constructors, fields, interfaces and inheritance for a supplied class. The class being X-rayed is specified by a String parameter which contains the name of the actual class. The code for the example is shown in Listing 4.

In order for the X-ray class program to determine the methods, constructors, fields and interfaces contained in the requested class, it must instantiate an object of the class by calling:

c = Class.forName(className);

After instantiating the class, the utility determines the selected operation on that class based on a second user-supplied string parameter, which can have one of the following values:

localMethods
allMethods
Constructors
fields
interface
inheritance

The local methods contained in the specified class may be found by calling:

methodList = c.getDeclaredMethods();

This call returns a Method[] that contains all the methods declared in the local class including private, protected and public. This call excludes inherited methods.

A list of all the public methods, both inherited and local, may be obtained by calling:

methodList = c.getMethods();

Constructor methods are not included in the return Method[] of this call. Retrieving a list of constructors for a specific class can be accomplished by calling:

constructorList = c.getDeclaredConstructors();

This call returns a constructor[] that contains all of the private, protected and public constructors declared on the local class. A list that includes only the public constructors can be constructed by calling:

constructorList = c.getConstructors();

Class variables can be retrieved as Field[] information. To access a complete list of fields from a class including private, protected and public, we call:

fieldList = c.getDeclaredFields();

A list that includes only the public fields can be retrieved by calling:

fieldList = c.getFields();

Information concerning the interfaces implemented by a class can be accessed by calling:

interfaceList = c.getInterfaces();

This call returns a Class[] that contains all of the interfaces implemented by the local class. Notice that this call doesn't have a getDeclaredInterfaces() counterpart like the other methods.

To access the inheritance information in the class, we get the name of each one of the superclasses in the inheritance tree. This is done in a while loop by calling:

classRef = c.getSuperclass();

We use this mechanism to return a class[] with all of the classes that participate in the extension of the local class. The output of the program for obtaining the inheritance hierarchy of the java.applet.Applet class is given in Figure 4.

Figure 4
Figure 4:

Notice that of the various methods presented on this section, the only method that recursively provided information contained in its inheritance tree was the c.getMethods() call. The other methods only provided information contained by the local class.

An X-Ray Bean
Our third example illustrates the use of Introspection to build a utility that allows us to view all the methods, properties and events for a supplied JavaBean class. The Bean being X-rayed is specified by a String parameter which contains the name of the actual Bean class. The code for the example is shown in Listing 3.

In order for the X-ray Bean program to determine the methods, properties and events contained in the requested class, it must instantiate an object of the class by calling:

c = Class.forName(className);

After instantiating the class, the utility must access the BeanInfo for the instantiated Bean. BeanInfo data can be accessed via the Introspector class by calling:

bi = Introspector.getBeanInfo(c);

Next, the utility determines the selected operation on that class based on the second user-supplied parameter entered at the command line (i.e., methods, properties and events). The localMethods contained by the specified Bean can be found by calling:

methodDescriptorList = bi.getMethodDescriptors();

This call returns a MethodDescriptor[] that contains a description of all of the methods contained by this Bean. The type of method descriptor returned by this call contains a complete list of all the public methods contained within the inheritance tree of this Bean. In order to access the actual method instances, we need to iterate through the methodDescriptionList and obtain the method by calling:

methodRef = methodDescriptorList[i].getMethod();

From each one of these values, we are able to build a Method[] list that can be displayed by the utility. This includes no constructor method information. To access the Bean constructor information, you must use reflection.

Bean properties can be retrieved via PropertyDescriptors by calling:

PropertyDescriptorList = bi.getPropertyDescriptors();

This call returns a PropertyDescriptor[] that contains a description of all of the properties contained by this Bean. This includes name, readMethod, writeMethod, type, EditorClass, etc. Our utility uses this information to get the readMethod, writeMethod and property name via the PropertyDescriptor superclass (i.e., FeatureDescriptor) by calling:

methodRef = PropertyDescriptorList[i].getReadMethod();
methodRef = PropertyDescriptorList[i].getWriteMethod();
propertyName = PropertyDescriptorList[i].getName();

Bean events can be retrieved via EventSetDescriptors by calling:

eventSetDescriptorList = bi.getEventSetDescriptors();

This call returns an EventSetDescriptor[] that contains a description of all the methods associated with each event for this Bean. Our utility uses this information to get a Method[] for each one of the returned events in the eventSetDescriptorList. This is accomplished by calling:

methodList = eventSetDescriptorList[i].getListenerMethods();

This information is used to identify the methods associated to each one of the listener methods.

Information concerning the interfaces implemented by a class can be accessed by calling:

interfaceList = c.getInterfaces();

This call returns a class[] that contains all the interfaces implemented by the local class. Notice that this call doesn't have a getDeclaredInterfaces() counterpart like the other methods.

The output from the program for examining the events in the class, com.sun.swing.Jpanel is shown in Figure 5.

Figure 5
Figure 5:

Conclusion
In this article, we took a look at the Reflection and Introspection APIs and used them to develop several useful utilities for Java development. In our next article, we will use the concepts and utilities introduced here to develop a new category of dynamically generated adapters called Dynamic Adapters.

The traditional Adapter design pattern is defined as follows: Adapter: "Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces." [Design Patterns: Elements of Resuable Object-Oriented Software, Gamma et. al., Addison Wesley, 1995.]

Adapters are used when the input and output interfaces are known at compile-time. Dynamic Adapters will allow a program to dynamically map the interfaces at runtime. We will examine these patterns in more detail in the next article.

About the Authors
Ajit Sagar is a member of the Technical Staff at i2 Technologies, Dallas, TX. He holds an M.S. in Computer Science from Mississippi State University. Ajit focuses on UI, networking and middleware architecture development.He has 7-1/2 years of programming experience, two in Java. Ajit can be reached at Ajit_Sagar@i2.com

Israel Hilerio is a Member of the Technical Staff at i2 Technologies, Dallas, TX. He holds a B.S. in Computer Science Engineering from St. Mary's University, TX and an M.S. in Computer Science from Southern Methodist University, Dallas, TX. He has 8 years of programming experience, 2 1/2 years in Java. Israel can be reached at Israel_Hilerio@i2.com

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: info@sys-con.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.