Reflection: Run-time class Information

If you don't know the exact type of an object, Rtti will help us investigate. But there is a limit: the type must be known during compilation, otherwise it cannot be investigated with Rtti, and then the next step cannot be carried out. In other words, the compiler must have a clear idea of all the classes Rtti to handle.
On the surface, this doesn't seem like a big limitation, but what happens if you get a handle to an object that isn't in your own programming space? In fact, object classes cannot be used by our programs even during compilation. For example, suppose we get a series of bytes from a disk or network and are told that the bytes represent a class. Because the compiler does not know the class when compiling the code, how can you use the class successfully?
In the traditional programming environment, the probability of this situation may be very small. But when we move to a larger programming world, we must attach great importance to this problem. The first one to note is component-based programming. In this environment, we use the Rapid Application Development (RAD) model to build program projects. Rad is typically built into the Application Builder tool. This is a visual way of coding (appearing on the screen as a form). You can drag an icon representing a different component to a form. Then, configure them correctly by setting the properties or values of these components. The configuration during design requires that any component is "illustrated" (that is, it is free to obtain an instance of them). These components also reveal a portion of their content, allowing programmers to read and set various values. In addition, the components used to control GUI events must uncover information about the appropriate methods so that the RAD environment helps programmers overwrite these event-driven methods with their own code. Reflection provides a special mechanism for detecting available methods and generating method names. Java 1.1 provides an infrastructure for this component-based program design through the Java Beans, which is described in detail in the 13th chapter.
Another driving force for querying class information at run time is to create and execute objects on a remote system over the network. This is called "Remote Method call" (RMI), which allows Java programs (more than version 1.1) to use objects that are published or distributed by multiple machines. The distribution of this object may be caused by a number of reasons: it is possible to do a computationally intensive work, want to split it, let the rest of the machine to share part of the work, so as to speed up processing progress. In some cases, it may be necessary to place code that controls specific types of tasks, such as "operating Rules" in a multi-tier client/server architecture, on a particular machine, making the machine a general-purpose repository for describing those actions. And you can easily modify the site to make it affect all aspects of the system (this is a particularly useful design ideas, because the machine is independent, so can easily modify the software!) ）。 Distributed computing can also give more full play to the role of some proprietary hardware, which is particularly adept at performing certain tasks-such as matrix reversals-but is too exaggerated or too expensive for conventional programming.
In Java 1.1, class classes (discussed in detail earlier in this chapter) have been extended to support the concept of "reflection." For Field,method and constructor classes (each implements the memberinterface--member interface), they all have a new library: Java.lang.reflect. These types of objects are created by the JVM at run time and are used to represent the corresponding members in the unknown class. This allows the builder to create new objects, read and modify the fields associated with the Field object with the Get () and set () methods, and Invoke the Invoke () method to call the methods associated with the method object. In addition, we can Invoke method GetFields (), GetMethods (), GetConstructors (), respectively, to return an array of objects that represent fields, methods, and builders (in the online documentation, you can also find more information about the class class). As a result, class information for anonymous objects can be fully exposed during runtime, and nothing needs to be known during compilation.
The important thing to know is that there is nothing magical about "reflection". When dealing with an object of unknown type through reflection, the JVM simply checks that object and investigates which particular class it belongs to (as in previous rtti). But after that, the class object must be loaded before we do anything else. Therefore, the. class file for that particular type must be invoked by the JVM (either within the local machine or through the network). So the only difference between Rtti and "reflection" is that for Rtti, the compiler opens and checks the. class file at compile time. In other words, we can call all methods of an object in a "normal" way, but for reflection, the. class file is not available during compilation, but is opened and checked by the run-time environment.