📄 constantpool.doc.html
字号:
</ul>
<a name="65572"></a>
<li>If the <code>class</code> file for class or interface C is successfully verified, the class or interface is prepared. Preparation involves creating the static fields for the class or interface and initializing those fields to their standard default values <a href="Concepts.doc.html#15858">(§2.5.1)</a>. Preparation should not be confused with the execution of static initializers <a href="Concepts.doc.html#16396">(§2.11)</a>; unlike execution of static initializers, preparation does not require the execution of any Java code. During preparation:
<ul>
<a name="65579"></a>
<li>If a class that is not declared <code>abstract</code> has an <code>abstract</code> method, class resolution throws an <code>AbstractMethodError</code>.
</ul>
<a name="67250"></a>
<li> Certain checks that are specific to individual Java Virtual Machine instructions, but that are logically related to this phase of constant pool resolution, are described in the documentation of those instructions. For instance, the <i>getfield</i> instruction resolves its field reference, and only afterward checks to see whether that field is an instance field (that is, it is not <code>static</code>). Such exceptions are still considered and documented to be linking, not runtime, exceptions.
<a name="66906"></a>
<li>Next, the class is initialized. Details of the initialization procedure are given in <a href="Concepts.doc.html#24237">§2.16.5</a> and in <i>The Java Language Specification</i>.
<ul>
<a name="65629"></a>
<li>If an initializer completes abruptly by throwing some exception E, and if the class of E is not <code>Error</code> or one of its subclasses, then a new instance of the class <code>ExceptionInInitializerError</code>, with E as the argument, is created and used in place of E.
<a name="67315"></a>
<li>If the Java Virtual Machine attempts to create a new instance of the class <code>ExceptionInInitializerError</code> but is unable to do so because an <code>Out-Of--Memory-Error</code> occurs, then the <code>OutOfMemoryError</code> object is thrown instead.
</ul>
<a name="51507"></a>
<li>Finally, access permissions to the class being resolved are checked:
<ul>
<a name="67569"></a>
<li>If the current class or interface does not have permission to access the class or interface being resolved, class or interface resolution throws an <code>Illegal-Access-Error</code>. This condition can occur, for example, if a class that is originally declared <code>public</code> is changed to be <code>private</code> after another class that refers to the class has been compiled.
</ul>
</ol>
<a name="67561"></a>
If none of the preceding errors were detected, constant pool resolution of the class or interface reference must have completed successfully. However, if an error was detected, one of the following must be true.<p>
<ul><a name="67630"></a>
<li>If some exception is thrown in steps 1-4, the class being resolved must have been marked as unusable or must have been discarded.
<a name="67631"></a>
<li>If an exception is thrown in step 5, the class being resolved is still valid and usable.
</ul><a name="67641"></a>
In either case, the resolution fails, and the class or interface attempting to perform
the resolution is prohibited from accessing the referenced class or interface.
<p><a name="67374"></a>
<h3>5.1.2 Current Class or Interface Loaded by a Class Loader</h3>
<a name="67375"></a>
If a class or interface, loaded using a class loader, references a non-array class or
interface C, then that same class loader is used to load C. The <code>loadClass</code> method of
that class loader is invoked on the fully qualified path name <a href="Concepts.doc.html#20207">(§2.7.9)</a> of the class to
be resolved. The value returned by the <code>loadClass</code> method is the resolved class. The
remainder of the section describes this process in more detail.
<p><a name="63496"></a>
Every class loader is an instance of a subclass of the abstract class <code>ClassLoader</code>. Applications implement subclasses of <code>ClassLoader</code> in order to extend the manner in which the Java Virtual Machine dynamically loads classes. Class loaders can be used to create classes that originate from sources other than files. For example, a class could be downloaded across a network, it could be generated on the fly, or it could be decrypted from a scrambled file.<p>
<a name="63724"></a>
The Java Virtual Machine invokes the <code>loadClass</code> method of a class loader in order to cause it to load (and optionally link and initialize) a class. The first argument to <code>loadClass</code> is the fully qualified name of the class to be loaded. The second argument is a boolean. The value <code>false</code> indicates that the specified class must be loaded, but not linked or initialized; the value <code>true</code> indicates the class must be loaded, linked, and initialized.<p>
<a name="63719"></a>
Implementations of class loaders are required to keep track of which classes they have already loaded, linked, and initialized:<a href="#63902"><sup>2</sup></a><p>
<ul><a name="63735"></a>
<li>If a class loader is asked to load (but not link or initialize) a class or interface that it has already loaded (and possibly already linked and initialized), then it should simply return that class or interface.
<a name="63739"></a>
<li>If a class loader is asked to load, link, and initialize a class or interface that it has already loaded but not yet linked and initialized, the class loader should not reload the class or interface, but should only link and initialize it.
<a name="63748"></a>
<li>If a class loader is asked to load, link, and initialize a class or interface that it has already loaded, linked, and initialized, the class loader should simply return that class or interface.
</ul><a name="63764"></a>
When the class loader's <code>loadClass</code> method is invoked with the name of a class or interface that it has not yet loaded, the class loader must perform one of the following two operations in order to load the class or interface:<p>
<ul><a name="66454"></a>
<li>The class loader can create an array of bytes representing the bytes of a file of <code>class</code> file format; it then must invoke the method <code>defineClass</code> of class <code>ClassLoader</code> on those bytes to convert them into a class or interface with this class loader as the class loader for the newly defined class. Invoking <code>define-Class</code> causes the Java Virtual Machine to perform step 1<a href="ConstantPool.doc.html#67947">a</a> of <a href="ConstantPool.doc.html#65190">§5.1.1</a>.
<a name="66461"></a>
<li>Invoking <code>defineClass</code> then causes the <code>loadClass</code> method of the class loader to be invoked recursively in order to load the superclass of the newly defined class or interface. The fully qualified path name of the superclass is derived from the <code>super_class</code> item in the <code>class</code> file format. When the superclass is loaded in, the second argument to <code>loadClass</code> is <code>false</code>, indicating that the superclass is not to be linked and initialized immediately.
<a name="66247"></a>
<li>The class loader can also invoke the static method <code>findSystemClass</code> in class <code>ClassLoader</code> with the fully qualified name of the class or interface to be loaded. Invoking this method causes the Java Virtual Machine to perform step  <a href="ConstantPool.doc.html#67945">1</a> of <a href="ConstantPool.doc.html#65190">§5.1.1</a>. The resulting <code>class</code> file is not marked as having been loaded by a class loader.
</ul><a name="66248"></a>
After the class or interface and its superclasses have been loaded successfully, if the second argument to <code>loadClass</code> is <code>true</code> the class or interface is linked and initialized. This second argument is always <code>true</code> if the class loader is being called upon to resolve an entry in the constant pool of a class or interface. The class loader links and initializes a class or interface by invoking the method <code>resolveClass</code> in the class <code>ClassLoader</code>. Linking and initializing a class or interface created by a class loader is very similar to linking and initializing a class or interface without a class loader (steps 2-4 of <a href="ConstantPool.doc.html#65190">§5.1.1</a>):<p>
<a name="63839"></a>
First, the superclass of the class or interface is linked and initialized by calling the <code>loadClass</code> method of the class loader with the fully qualified name of the superclass as the first argument, and <code>true</code> as the second argument. Linking and initialization may result in the superclass's own superclass being linked and initialized. Linking and initialization of a superclass must detect any of the errors of step 3 of <a href="ConstantPool.doc.html#65190">§5.1.1</a>.<p>
<a name="66360"></a>
Next, the bytecode verifier is run on the class or interface being linked and initialized. The verifier may itself need classes or interfaces to be loaded, and if so, it loads them by invoking the <code>loadClass</code> method of the same class loader with the second argument being <code>false</code>. Since verification may itself cause classes or interfaces to be loaded (but not linked or initialized, to avoid circularity), it must detect the errors of step 1 of <a href="ConstantPool.doc.html#65190">§5.1.1</a> for any classes or interfaces it attempts to load. Running the verifier may also cause the errors of step  3a of <a href="ConstantPool.doc.html#65190">§5.1.1</a>.<p>
<a name="66373"></a>
If the class file is successfully verified, the class or interface is then prepared (step 3b of <a href="ConstantPool.doc.html#65190">§5.1.1</a>) and initialized (step  4 of <a href="ConstantPool.doc.html#65190">§5.1.1</a>).<p>
<a name="66416"></a>
Finally, access permissions to the class or interface are checked (step 5 of <a href="ConstantPool.doc.html#65190">§5.1.1</a>). If the current class or interface does not have permission to access the class being resolved, class resolution throws an <code>IllegalAccessError</code> exception.<p>
<a name="66419"></a>
If none of the preceding errors were detected, loading, linking, and initialization of the class or interface must have completed successfully. <p>
<a name="65204"></a>
<h3>5.1.3 Array Classes</h3>
<a name="65747"></a>
A constant pool entry tagged as <code>CONSTANT_Class</code> <a href="ClassFile.doc.html#1221">(§4.4.1)</a> represents an array class
if the first character of the UTF-8 string <a href="ClassFile.doc.html#7963">(§4.4.7)</a> referenced by the <code>name_index</code> item
of that constant pool entry is a left bracket ("<code>[</code>"). The number of initial consecutive
left brackets in the name represents the number of dimensions of the array class.
Following the one or more initial consecutive left brackets is a field descriptor
<a href="ClassFile.doc.html#14152">(§4.3.2)</a> representing either a primitive type or a non-array reference type; this field
descriptor represents the <i>base type</i> of the array class.
<p><a name="65673"></a>
The following steps are performed to resolve an array class referenced from the constant pool of a class or interface:<p>
<ol>
<a name="65665"></a>
<li>Determine the number of dimensions of the array class and the field descriptor that represents the base type of the array class.
<a name="67653"></a>
<li>Determine the base type of the array class:
</ol>
<ul><a name="67654"></a>
<li>If the field descriptor represents a primitive type (its first character is not "<code>L</code>"), that primitive type is the base type of the array class.
<a name="67655"></a>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -