TIJ——Chapter Fourteen:Type Information

• Runtime type information(RTTI) allows you to discover and use type information while a program is running.
• All classes are loaded into the JVM dynamically, upon the first use of a class. This happens when the program makes the first reference to a static member of that class. It turns out that the constructor is also a static method of a class, even though the static keyword is not used for  a constructor. Therefore, creating a new object of that class using the new operator also counts as a reference to a static member of the class.
• The class loader first checks to see if the Class Object for that type is loaded. If not, the default class loader finds the .class file with that name(an add-on class loader might, for example, look for the bytecodes in a database instead). As the bytes for the class are loaded, they are verified to ensure that they have not been corrupted and that they do not comprise bad Java code(this is one of the lines of defense for security in Java). Once the Class object for that type is in memory, it is used to create all object of that type.
• Java provides a second way(except Class.forName()) to produce the reference to the Class object: the class literal. This would look like: java.util.ArrayList.class; which is not only simpler, but also safer since it's checked at compile time(and thus does not need to be placed in a try block). Because it eliminates the forName() method call, it's also more efficient. Class literals work with regular classes as well as interfaces, arrays, and primitive types. In addition, there's a standard field called TYPE that exists for each of the primitive wrapper classes. The TYPE field produces a reference to the Class object for the associated primitive type, such as: boolean.class is equivalent to Boolean.TYPE.

---

• It's interesting to note that creating a reference to a Class obejct using ".class" doesn't automatically initialize the Class object. There are actually three steps in preparing a class for use:Effectively, initialization is "as lazy as possible." Just using the .class syntax to get a reference to the class doesn't cause initialization. However, Class.forName() initializes the class immediately in order to produce the Class reference. If a static final value is a "compile-time constant", that value can be read without causing the corresponding class to be initialized. Making a field static and final, however, does not guarantee this behavior(forces class initialization if it don't be a compile-time constant). If a static field is not final, accessing it always requires linking(to allocate storage for the field) and initialization(to initialize that storage) before it can be read.
  1. Loading, which is performed by the class loader. This finds the bytecodes(usually, but not necessarily, on your disk in your classpath) and create a Class object from those bytecodes.
  2. Linking. The linke phase verifies the bytecodes in the class, allocates storage for static fields, and if necessary, resovles all references to other classes made by this class.
  3. Initialization. If there's a superclass, initialize that. Execute static initializers and static initialization blocks.
  • 注: Initialization is delayed until the first reference to a static method(the constructor is implicitly static) or to a non-constant static field.
• Effectively, initialization is "as lazy as possible". Just using the .class syntax to get a reference to a class doesn't cause initialization. However, Class.forName() initializes the class immediately in order to produce the Class reference. If a static final value is a "compile-time constant", that value can be read without causing the corresponding class to be initialized. Making a field static and final, however, does not guarantee this behavior(force class initialization if it don't be a compile-time constant). If a static field is not final, accessing it always requires linking(to allocate storage for the field) and initialization(to initialize that storage) before it can be read.

---

• The reason for adding the generic syntax to Class references is only to provide compile-time type checking, so that if you do something wrong you find out about it a little sooner.
• It's important to use instanceof before a downcast when you don't have other information that tells you the type of the object; otherwise, you'll end up with a ClassCastException.
• 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 an ordinary RTTI). Before anything can be done with it, the Class object must be loaded. Thus, the .class file for that particular type must still be available to the JVM, either on the local machine or across the network. So the true difference between RTTI and reflections 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 runtime environment.

静态代理VS动态代理：

对于静态代理，一个委托类对应一个代理类，因此过度使用静态代理会导致大量的代理类产生。于是出现了动态代理，对于相同逻辑的代理，我们只需要动手实现一遍，就可以以相同的处理方式代理不同的委托类。