Why does Java support Reflection? The answer is that the Java runtime still has type information. It contains all the fields, methods, protection levels, and other classes that the class depends on. In Java, Class information is stored as objects. These objects are meta objects and their types are Class. With this information, it is easy to dynamically create an object or call some methods. In C ++, through RTTI (runtime type recognition), we can also know some information about the class, But why C ++ does not have Reflection, the reason is that the type information is incomplete. The RTTI name tells us that the type information of C ++ is used for type recognition, so it does not need any additional information. C ++ does not want to do this, but does not want to add additional burden to users. C ++ has abandoned the object. Bjarne Stroustrup, the father of C ++, is discussed in depth in section 14.2.8 of his C ++ language design and evolution.
The object is the material basis of Java Reflection. What is its spiritual basis? Why does Java support Reflection? After the above discussion, we further discuss this question. Why does Java provide metadata?
To discuss this issue, we need to pull back to a decade ago, when Java just came to the stage of formal history. Java was actually born several years ago. It was also called Oak at that time, and the environmental limitations made this epoch masterpiece shelved when it was released. When Netscape set off as the prelude to the network drama, Java was able to become a Phoenix. One of the important reasons was that Java was network-centric.
After careful observation, we will find that the entire Java infrastructure is designed to serve the network. The first is the most famous cross-platform in Java. In fact, in the years before Java, people also need to consider the portability between platforms. However, most of such transplantation is at the source code level, which is one of the reasons why C languages can become popular, in a single-host environment, the platform differences are not that obvious. The emergence of the Network highlights the differences between platforms, because the network may be connected to a variety of computers and devices. Yes, there are still devices. You may know that the initial development of Java was related to embedded devices. Once the application can be cross-platform, the program development and post-management and maintenance work will be greatly simplified, and portability will also be upgraded from the source code level to the binary level (Java bytecode ). Therefore, cross-platform is actually designed to lay the foundation for the network. Another important point in Java-security is more closely related to the network. Everyone can come up with several reasons to associate the two.
Let's take a look at how the Java infrastructure supports the network. Do you still remember how attractive Java was originally? That's right, Applet. Anyone familiar with the principle knows that the Applet is run by downloading remote class files to a local machine for execution. Compared with the local hard disk, the network is a word ---- slow. If Java uses the traditional way of organizing executable files, that is, a complete executable file, and downloads the entire Applet and runs it, I am afraid that the flowers will thank you. Java uses a method to split files and organize them in class units. This is the class file we saw today. In this way, the execution process becomes the first class that can be run after download, greatly saving the initial waiting time. A good design will divide the program into several modules. Therefore, the vast majority of programs cannot be written in a class. Therefore, the class file must contain the classes it uses. For the pilot part, we can let it start to execute in a specific way. For example, we put the familiar main method in a specific byte, but for any method without a definite method, there is no way to stipulate, and a class calls the method of another class is so casual, so the class file must contain the information of this class method, further field information will also be added, in this way, almost a complete class information is generated, and the information corresponds to a metadata object. Therefore, Meta objects appear in the Java infrastructure.
With metadata, Reflection has become a natural thing. With Reflection, Java also has the ability to dynamically expand, which can greatly improve the flexibility of the program.
You can also say a few words about the network support of the Java infrastructure. The class file has been carefully designed and is quite compact. Its purpose is to facilitate transmission over the network. The emergence of JAR files aims to facilitate network transmission, if only one class is transferred at a time, a large amount of time will be wasted in establishing a network connection. The JAR file makes it possible to transmit multiple classes at a time, we also know that the data in the JAR file is compressed, which further reduces the download time. The Java infrastructure supports the network. In section 4.3 of "deep into Java Virtual Machine" (version 2), I will elaborate on it. If you are interested, take a look.
Thinking about Reflection gives me the opportunity to think deeply about Java's design. A good software design requires a core concept as the support. Everything is centered around the core, and for Java, this core is the network.
An interesting thinking experience!