Dynamic introspection
 
This article explains about the Java classes and its ability to perform dynamic introspection at the Java Reflection API. It is the ability to look inside classes that are already loaded. It also makes aware about the new Java 1.1 tools for finding out information about classes.
 
 
The effectiveness of introspection
 
 
Java was designed with the supposition that the situation in which it was running would be changing dynamically. These 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. Here, 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 series. 
 
What are Anonymous classes?

It is difficult to describe and design anonymous classes. Writing a program that can incorporate that object into its continuing operation is the challenge of supporting an anonymous class. The general solution is rather difficult, but by constraining the problem, some specialized solutions can be created. 
 
Two examples provide specialized solutions to this class problem in the 1.0 version of Java: 
 
Java applets: 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 super classes, like Applet, and Java interfaces, like Applet Context, 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 super class. 
 
 
The command-line version of the Java interpreter: The downside of a common super class 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 Applet Context. 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 Hash table 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.   
 
 
Also introspection helps to solve a problem. That is in figuring out how to start execution in a class that the command-line version of the Java virtual machine has just loaded. Here the virtual machine has to invoke some static method in the loaded class. By convention, that method is named main and takes a single argument.  
 
 
The inspiration for dynamic solutions
 
 
The challenge with the existing Java 1.0 architecture is that there are problems that could be solved by a more dynamic introspection environment -- such as loadable UI components, loadable device drivers in a Java-based OS, and dynamically configurable editing environments. 
 
JavaBeans: The "killer app," or the issue that caused the Java Reflection API to be created, was the development of an object component model for Java. That model is now known as JavaBeans. 
 
User interface components: They are an ideal design point for an introspection system because they have two very different consumers. On the one hand, the component objects are linked together to form a user interface as part of some application. 
 
Conclusion
 
On the other hand, there needs to be an interface for tools that manipulate user components without having to know what the components are, or, more importantly, without access to the components' source code. The Java Reflection API grew out of the needs of the JavaBeans user interface component API. And they work well.