This is a visual
approach to creating a program (which you see on the screen as a “form”)
by moving icons that represent components onto the form. These
components are then configured by setting some of their values at
program time. This design-time configuration requires that any
component be instantiable, that it exposes parts of itself, and that it allows
its values to be read and set. In addition, components that handle GUI
events must expose information about appropriate methods so that the
RAD environment can assist the programmer in overriding these event-
handling methods. Reflection provides the mechanism to detect the
available methods and produce the method names. Java provides a
structure for component-based programming through JavaBeans
(described in Chapter 14). Feedback
Chapter 10: Detecting Types
471
Another compelling motivation for discovering class information at run
time is to provide the ability to create and execute objects on remote
platforms across a network. This is called Remote Method Invocation
(RMI) and it allows a Java program to have objects distributed across
many machines. This distribution can happen for a number of reasons:
for example, perhaps you’re doing a computation-intensive task and you
want to break it up and put pieces on machines that are idle in order to
speed things up. In some situations you might want to place code that
handles particular types of tasks (e.g., “Business Rules” in a multitier
client/server architecture) on a particular machine, so that machine
becomes a common repository describing those actions and it can be
easily changed to affect everyone in the system. (This is an interesting
development, since the machine exists solely to make software changes
easy!) Along these lines, distributed computing also supports specialized
hardware that might be good at a particular task—matrix inversions, for
example—but inappropriate or too expensive for general purpose
programming. Feedback
The class Class (described previously in this chapter) supports the
concept of reflection, and there’s an additional library,
java.lang.reflect, with classes Field, Method, and Constructor
(each of which implement the Member interface). Objects of these
types are created by the JVM at run time to represent the corresponding
member in the unknown class. You can then use the Constructors to
create new objects, the get( ) and set( ) methods to read and modify the
fields associated with Field objects, and the invoke( ) method to call a
method associated with a Method object. In addition, you can call the
convenience methods getFields( ), getMethods( ),
getConstructors( ), etc., to return arrays of the objects representing the
fields, methods, and constructors. (You can find out more by looking up
the class Class in the JDK documentation.) Thus, the class information
for anonymous objects can be completely determined at run time, and
nothing need be known at compile time. Feedback
It’s important to realize that there’s nothing magic about reflection. When
you’re using reflection to interact with an object of an unknown type, the
JVM will simply look at the object and see that it belongs to a particular
class (just like ordinary RTTI) but then, before it can do anything else, the
Class object must be loaded. Thus, the .class file for that particular type 472
Thinking in Java
www.BruceEckel.com
must still be available to the JVM, either on the local machine or across
the network. So the true difference between RTTI and reflection is that
with RTTI, the compiler opens and examines the .class file at compile
time. Put another way, you can call all the methods of an object in the
“normal” way. With reflection, the .class file is unavailable at compile
time; it is opened and examined by the run-time environment. Feedback
A class method extractor
You’ll rarely need to use the reflection tools directly; they’re in the
language to support other Java features, such as object serialization
(Chapter 12) and JavaBeans (Chapter 14). However, there are times when
it’s quite useful to be able to dynamically extract information about a
class. One extremely useful tool is a class method extractor. As mentioned
before, looking at a class definition source code or JDK documentation
shows only the methods that are defined or overridden within that class
definition. But there could be dozens more available to you that have
come from base classes. To locate these is both tedious and time
consuming1. Fortunately, reflection provides a way to write a simple tool
that will automatically show you the entire interface. Here’s the way it
works:
//: c10:ShowMethods.java
// Using reflection to show all the methods of a class,
// even if the methods are defined in the base class.
// {Args: ShowMethods}
import java.lang.reflect.*;
import java.util.regex.*;
public class ShowMethods {
private static final String usage =
"usage: \n" +