📄 constantpool.doc.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><html><head><title>VM Spec Loading, Linking, and Initializing</title></head><body BGCOLOR=#eeeeff text=#000000 LINK=#0000ff VLINK=#000077 ALINK=#ff0000><table width=100%><tr><td><a href="VMSpecTOC.doc.html">Contents</a> | <a href="ClassFile.doc.html">Prev</a> | <a href="Instructions.doc.html">Next</a> | <a href="VMSpecIX.fm.html">Index</a></td><td align=right><i><i>The Java<sup><font size=-2>TM</font></sup> Virtual Machine Specification</i></i></td></tr></table><hr><br> <a name="67960"></a><p><strong>CHAPTER 5 </strong></p><a name="67962"></a><h1>Loading, Linking, and Initializing</h1><hr><p><a name="86731"></a>The Java virtual machine dynamically loads <a href="Concepts.doc.html#19175">(§2.17.2)</a>, links <a href="Concepts.doc.html#22574">(§2.17.3)</a>, and initializes<a href="Concepts.doc.html#19075">(§2.17.4)</a> classes and interfaces. Loading is the process of finding the binary representationof a class or interface type with a particular name and <i>creating</i> a class or interface from that binary representation. Linking is the process of taking a class or interface and combining it into the runtime state of the Java virtual machine so that it can be executed. Initialization of a class or interface consists of executing the class or interface initialization method <code><clinit></code> <a href="Overview.doc.html#12174">(§3.9)</a>.<p><a name="86744"></a>In this chapter, <a href="ConstantPool.doc.html#73272">Section 5.1</a> describes how the Java virtual machine derives symbolic references from the binary representation of a class or interface. <a href="ConstantPool.doc.html#51579">Section 5.2</a> explains how the processes of loading, linking, and initialization are first initiated by the Java virtual machine. <a href="ConstantPool.doc.html#72007">Section 5.3</a> specifies how binary representations of classes and interfaces are loaded by class loaders and how classes and interfaces are created. Linking is described in <a href="ConstantPool.doc.html#71418">Section 5.4</a>. <a href="ConstantPool.doc.html#77976">Section 5.5</a> details how classes and interfaces are initialized. Finally, <a href="ConstantPool.doc.html#74727">Section 5.6</a> introduces the notion of binding native methods.<p><a name="73272"></a><hr><h2>5.1 The Runtime Constant Pool</h2><a name="73342"></a>The Java virtual machine maintains a per-type constant pool <a href="Overview.doc.html#22972">(§3.5.5)</a>, a runtime data structure that serves many of the purposes of the symbol table of a conventional programminglanguage implementation. <p><a name="73367"></a>The <code>constant_pool</code> table <a href="ClassFile.doc.html#20080">(§4.4)</a> in the binary representation of a class or interface is used to construct the runtime constant pool upon class or interface creation <a href="ConstantPool.doc.html#72007">(§5.3)</a>. All references in the runtime constant pool are initially symbolic. The symbolic references in the runtime constant pool are derived from structures in the binary representation of the class or interface as follows:<p><ul><li>A symbolic reference to a class or interface is derived from a <code>CONSTANT_Class_info</code> structure <a href="ClassFile.doc.html#1221">(§4.4.1)</a> in the binary representation of a class or interface. Such a reference gives the name of the class or interface in the form returned by the <code>Class.getName</code> method, that is:<p><ul><li>For a nonarray class or an interface, the name is the fully qualified name of the class or interface.<p><li>For an array class of M dimensions, the name begins with M occurrences of the ASCII "[" character followed by a representation of the element type:<p><ul><li>If the element type is a primitive type, it is represented by the corresponding field descriptor <a href="ClassFile.doc.html#14152">(§4.3.2)</a>.<p><li>Otherwise, if the element type is a reference type, it is represented by the ASCII "L" character followed by the fully qualified name of the element type followed by the ASCII ";" character.<p></ul></ul><li>Whenever this chapter refers to the name of a class or interface, it should be understood to be in the form returned by the <code>Class.getName</code> method.<p><li>A symbolic reference to a field of a class <a href="Concepts.doc.html#16338">(§2.9)</a> or an interface <a href="Concepts.doc.html#18349">(§2.13.3.1)</a> is derived from a <code>CONSTANT_Fieldref_info</code> structure <a href="ClassFile.doc.html#42041">(§4.4.2)</a> in the binary representation of a class or interface. Such a reference gives the name and descriptor of the field, as well as a symbolic reference to the class or interface in which the field is to be found.<p><li>A symbolic reference to a method of a class <a href="Concepts.doc.html#16317">(§2.10)</a> is derived from a <code>CONSTANT_Methodref_info</code> structure <a href="ClassFile.doc.html#42041">(§4.4.2)</a> in the binary representation of a class or interface. Such a reference gives the name and descriptor of the method, as well as a symbolic reference to the class in which the method is to be found.<p><li>A symbolic reference to a method of an interface <a href="Concepts.doc.html#16432">(§2.13)</a> is derived from a <code>CONSTANT_InterfaceMethodref_info</code> structure <a href="ClassFile.doc.html#42041">(§4.4.2)</a> in the binary representation of a class or interface. Such a reference gives the name and descriptor of the interface method, as well as a symbolic reference to the interface in which the method is to be found.</ul><a name="80027"></a>In addition, certain nonreference runtime values are derived from items found in the <code>constant_pool</code> table:<p><ul><li>A string literal <a href="Concepts.doc.html#20359">(§2.3)</a> is derived from a <code>CONSTANT_String_info</code> structure <a href="ClassFile.doc.html#29297">(§4.4.3)</a> in the binary representation of a class or interface. The <code>CONSTANT_String_info</code> structure gives the sequence of Unicode characters constituting the string literal.<p><li>The Java programming language requires that identical string literals (that is, literals that contain the same sequence of characters) must refer to the same instance of class <code>String</code>. In addition, if the method <code>String.intern</code> is called on any string, the result is a reference to the same class instance that would be returned if that string appeared as a literal. Thus,<pre> <code>(</code>"<code>a</code>" + "<code>b</code>" + "<code>c</code>"<code>).intern()</code> == "<code>abc</code>"</pre> must have the value <code>true</code>.<p><li>To derive a string literal, the Java virtual machine examines the sequence of characters given by the <code>CONSTANT_String_info</code> structure. <p><ul><li>If the method <code>String.intern</code> has previously been called on an instance of class <code>String</code> containing a sequence of Unicode characters identical to that given by the <code>CONSTANT_String_info</code> structure, then the result of string literal derivation is a reference to that same instance of class <code>String</code>.<p><li>Otherwise, a new instance of class <code>String</code> is created containing the sequence of Unicode characters given by the <code>CONSTANT_String_info</code> structure; that class instance is the result of string literal derivation. Finally, the <code>intern</code> method of the new <code>String</code> instance is invoked.<p></ul><li>Runtime constant values are derived from <code>CONSTANT_Integer_info</code>, <code>CONSTANT_Float_info</code>, <code>CONSTANT_Long_info</code>, or <code>CONSTANT_Double_info </code>structures (<a href="ClassFile.doc.html#21942">§4.4.4</a>, <a href="ClassFile.doc.html#1348">§4.4.5)</a> in the binary representation of a class or interface. Note that <code>CONSTANT_Float_info</code> structures represent values in IEEE 754 single format and <code>CONSTANT_Double_info</code> structures represent values in IEEE 754 double format (<a href="ClassFile.doc.html#21942">§4.4.4</a>, <a href="ClassFile.doc.html#1348">§4.4.5)</a>. The runtime constant values derived from these structures must thus be values that can be represented using IEEE 754 single and double formats, respectively.</ul><a name="75097"></a>The remaining structures in the <code>constant_pool</code> table of the binary representation of a class or interface, the <code>CONSTANT_NameAndType_info</code> <a href="ClassFile.doc.html#1327">(§4.4.6)</a> and <code>CONSTANT_Utf8_info</code> <a href="ClassFile.doc.html#7963">(§4.4.7)</a> structures are only used indirectly when deriving symbolic references to classes, interfaces, methods, and fields, and when deriving string literals.<p><a name="51579"></a><hr><h2>5.2 Virtual Machine Start-up</h2><a name="72012"></a>The Java virtual machine starts up by creating an initial class, which is specified in an implementation-dependent manner, using the bootstrap class loader <a href="ConstantPool.doc.html#79383">(§5.3.1)</a>. The Java virtual machine then links the initial class, initializes it, and invokes its <code>public</code> class method <code>void</code> <code>main(String[])</code>. The invocation of this method drives all furtherexecution. Execution of the Java virtual machine instructions constituting the <code>main</code> method may cause linking (and consequently creation) of additional classes and interfaces, as well as invocation of additional methods.<p><a name="80548"></a>In some implementations of the Java virtual machine the initial class could be provided as a command line argument, as in JDK releases 1.0 and 1.1. Alternatively, the initial class could be provided by the implementation. In this case the initial class might set up a class loader that would in turn load an application, as in the Java 2 SDK, Standard Edition, v1.2. Other choices of the initial class are possible so long as they are consistent with the specification given in the previous paragraph.<p><a name="72007"></a><hr><h2>5.3 Creation and Loading</h2><a name="75047"></a>Creation of a class or interface C denoted by the name N consists of the constructionin the method area of the Java virtual machine <a href="Overview.doc.html#6656">(§3.5.4)</a> of an implementation-specific internal representation of C. Class or interface creation is triggered by another class or interface D, which references C through its runtime constant pool. Class or interface creation may also be triggered by D invoking methods in certain Java class libraries <a href="Overview.doc.html#15641">(§3.12)</a> such as reflection.<p><a name="76328"></a>If C is not an array class, it is created by loading a binary representation of C (see <a href="ClassFile.doc.html#80961">Chapter 4, "The class File Format"</a>) using a class loader <a href="Concepts.doc.html#19175">(§2.17.2)</a>. Array classes do not have an external binary representation; they are created by the Java virtual machine rather than by a class loader. <p><a name="74504"></a>There are two types of class loaders: user-defined class loaders and the bootstrap class loader supplied by the Java virtual machine. Every user-defined class loader is an instance of a subclass of the abstract class <code>ClassLoader</code>. Applications employ class loaders in order to extend the manner in which the Java virtual machine dynamically loads and thereby creates classes. User-defined class loaders can be used to create classes that originate from user-defined sources. For example, a class could be downloaded across a network, generated on the fly, or extracted from an encrypted file.<p><a name="77474"></a>A class loader L may create C by defining it directly or by delegating to another class loader. If L creates C directly, we say that L <i>defines</i> C or, equivalently, that L is the <i>defining loader</i> of C. <p><a name="77493"></a>When one class loader delegates to another class loader, the loader that initiates the loading is not necessarily the same loader that completes the loading and defines the class. If L creates C, either by defining it directly or by delegation, we say that L <i>initiates</i> loading of C or, equivalently, that L is an <i>initiating loader</i> of C. <p><a name="77925"></a>At run time, a class or interface is determined not by its name alone, but by a pair: its fully qualified name and its defining class loader. Each such class or interface belongs to a single <em>runtime package</em>. The runtime package of a class or interface is determined by the package name and defining class loader of the class or interface.<p><a name="74513"></a>The Java virtual machine uses one of three procedures to create class or interface C  denoted by N:<p><ul><li>If N denotes a nonarray class or an interface, one of the two following methods is used to load and thereby create C  :<p><ul><li>If D was defined by the bootstrap class loader, then the bootstrap class loader initiates loading of C <a href="ConstantPool.doc.html#79383">(§5.3.1)</a>.<p><li>If D was defined by a user-defined class loader, then that same user-defined class loader initiates loading of C <a href="ConstantPool.doc.html#79441">(§5.3.2)</a>. <p></ul><li>Otherwise N denotes an array class. An array class is created directly by the Java virtual machine <a href="ConstantPool.doc.html#79473">(§5.3.3)</a>, not by a class loader. However, the defining class loader of D is used in the process of creating array class C.</ul><a name="82266"></a>We will sometimes represent a class or interface using the notation <N, L<sub>d</sub>  >, where N denotes the name of the class or interface and L<sub>d</sub> denotes the defining loader of the class or interface. We will also represent a class or interface using the notation N<sup>L<sub>i</sub></sup>, where N denotes the name of the class or interface and L<sub>i</sub> denotes an initiating loader of the class or interface.<p><a name="79383"></a><h3>5.3.1 Loading Using the Bootstrap Class Loader</h3><a name="77261"></a>The following steps are used to load and thereby create the nonarray class or interfaceC denoted by N  using the bootstrap class loader.<p><a name="71463"></a>First, the Java virtual machine determines whether the bootstrap class loader has already been recorded as an initiating loader of a class or interface denoted by N. If so, this class or interface is C, and no class creation is necessary. <p><a name="76654"></a>Otherwise, the Java virtual machine performs one of the following two operations in order to load C:<p><ol><a name="71464"></a><li>The Java virtual machine searches for a purported representation of C in a platform-dependent manner. Note that there is no guarantee that a purported representation found is valid or is a representation of C.<p>Typically, a class or interface will be represented using a file in a hierarchical file system. The name of the class or interface will usually be encoded in the pathname of the file. <p>This phase of loading must detect the following error:<p><ul><li>If no purported representation of C  is found, loading throws an instance of <code>NoClassDefFoundError</code> or an instance of one of its subclasses.</ul><p>Then the Java virtual machine attempts to derive a class denoted by N  using the bootstrap class loader from the purported representation using the algorithm found in <a href="ConstantPool.doc.html#79388">Section 5.3.5</a>. That class is C. <p><li>The bootstrap class loader can delegate the loading of C to some user-defined class loader L  by passing N  to an invocation of a <code>loadClass</code> method on L. The result of the invocation is C. The Java virtual machine then records that the bootstrap loader is an initiating loader of C <a href="ConstantPool.doc.html#78621">(§5.3.4)</a>.</ol><a name="79441"></a><h3>5.3.2 Loading Using a User-defined Class Loader</h3><a name="79586"></a>The following steps are used to load and thereby create the nonarray class or interfaceC denoted by N    using a user-defined class loader L.<p><a name="79589"></a>First, the Java virtual machine determines whether L has already been recorded as an initiating loader of a class or interface denoted by N. If so, this class or interface is C, and no class creation is necessary. <p><a name="79449"></a>Otherwise the Java virtual machine invokes <code>loadClass(</code>N  <code>)</code> on L.<a href="#79448"><sup>1</sup></a> The value returned by the invocation is the created class or interface C. The Java virtual machine then records that L is an initiating loader of C <a href="ConstantPool.doc.html#78621">(§5.3.4)</a>. The remainder of this section describes this process in more detail. <p><a name="79453"></a>When the <code>loadClass</code> method of the class loader L is invoked with the name N of a class or interface C to be loaded, L must perform one of the following two operations in order to load C  :<p><ol><a name="85947"></a><li>The class loader L can create an array of bytes representing C as the bytes of a <code>ClassFile</code> structure <a href="ClassFile.doc.html#74353">(§4.1)</a>; it then must invoke the method <code>defineClass</code> of class <code>ClassLoader</code>. Invoking <code>defineClass</code> causes the Java virtual machine to derive a class or interface denoted by N    using L from the array of bytes using the algorithm found in <a href="ConstantPool.doc.html#79388">Section 5.3.5</a>.<p><a name="85957"></a><li>The class loader L can delegate the loading of C to some other class loader L<i>'</i>. This is accomplished by passing the argument N  directly or indirectly to an invocation of a method on L<i>'</i> (typically the <code>loadClass</code> method). The result of the invocation is C. ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -