constantpool.doc.html

java虚拟机规范

<p>This condition can occur, for example, if C is a class that was originally declared to be <code>public</code> but was changed to be non-<code>public</code> after D &#32;was compiled.
</ol>
<a name="77678"></a>
If steps 1 and 2 succeed but step 3 fails, C is still valid and usable. Nevertheless, resolution
fails, and D is prohibited from accessing C.
<p><a name="71685"></a>
<h4>5.4.3.2    Field Resolution</h4>
<a name="73232"></a>
To resolve an unresolved symbolic reference from D to a field in a class or interface 
C, the symbolic reference to C given by the field reference must first be resolved 
<a href="ConstantPool.doc.html#71636">(&#167;5.4.3.1)</a>. Therefore, any exception that can be thrown as a result of failure of resolution
of a class or interface reference can be thrown as a result of failure of field resolution.
If the reference to C can be successfully resolved, an exception relating to 
the failure of resolution of the field reference itself can be thrown. 
<p><a name="80823"></a>
When resolving a field reference, field resolution first attempts to look up the referenced field in C and its superclasses:<p>
<ol>
<a name="81200"></a>
<li>If C declares a field with the name and descriptor specified by the field reference, field lookup succeeds. The declared field is the result of the field lookup.<p>
<a name="83781"></a>
<li>Otherwise, field lookup is applied recursively to the direct superinterfaces of the specified class or interface C.<p>
<a name="81203"></a>
<li>Otherwise, if C has a superclass S, field lookup is applied recursively to S. <p>
<a name="81225"></a>
<li>Otherwise, field lookup fails.
</ol>
<a name="80871"></a>
If field lookup fails, field resolution throws a <code>NoSuchFieldError</code>. Otherwise, if field lookup succeeds but the referenced field is not accessible <a href="ConstantPool.doc.html#75929">(&#167;5.4.4)</a> to D, field resolution throws an <code>IllegalAccessError</code>.<p>
<a name="86894"></a>
Otherwise, let &lt;E, L1&gt; be the class or interface in which the referenced field is actually declared and let L2 be the defining loader of D. Let T be the name of the type of the referenced field. The Java virtual machine must impose the loading constraint that T<sup>L1</sup>=T<sup>L2</sup>(<a href="ConstantPool.doc.html#78621">&#167;5.3.4</a>). <p>
<a name="86899"></a>
<h4>5.4.3.3    Method Resolution</h4>
<a name="73131"></a>
To resolve an unresolved symbolic reference from D to a method in a class C, the 
symbolic reference to C given by the method reference is first resolved <a href="ConstantPool.doc.html#71636">(&#167;5.4.3.1)</a>. 
Therefore, any exceptions that can be thrown due to resolution of a class reference 
can be thrown as a result of method resolution. If the reference to C can be successfully
resolved, exceptions relating to the resolution of the method reference itself 
can be thrown. 
<p><a name="73062"></a>
When resolving a method reference:<p>
<ol>
<a name="73191"></a>
<li>Method resolution checks whether C is a class or an interface.<p>
<ul><li>If C is an interface, method resolution throws an <code>IncompatibleClassChangeError</code>.
</ul><p>
<a name="74255"></a>
<li>Method resolution attempts to look up the referenced method in C and its superclasses:<p>
<ul><li>If C declares a method with the name and descriptor specified by the method reference, method lookup succeeds.<p>
<li>Otherwise, if C has a superclass, step 2 of method lookup is recursively invoked on the direct superclass of C.
</ul><p>
<a name="71717"></a>
<li>Otherwise, method lookup attempts to locate the referenced method in any of the superinterfaces of the specified class C.<p>
<ul><li>If any superinterface of C declares a method with the name and descriptor specified by the method reference, method lookup succeeds.<p>
<li>Otherwise, method lookup fails.
</ul><a name="75187"></a>
</ol>
If method lookup fails, method resolution throws a <code>NoSuchMethodError</code>. If method lookup succeeds and the method is <code>abstract</code>, but C is not <code>abstract</code>, method resolution throws an <code>AbstractMethodError</code>. Otherwise, if the referenced method is not accessible <a href="ConstantPool.doc.html#75929">(&#167;5.4.4)</a> to D, method resolution throws an <code>IllegalAccessError</code>.<p>
<a name="77326"></a>
Otherwise, let &lt;E, L1&gt; be the class or interface in which the referenced method is actually declared and let L2 be the defining loader of D. Let T0 be the name of the type returned by the referenced method, and let T1, ..., Tn be the names of the argument types of the referenced method. The Java virtual machine must impose the loading constraints Ti<sup>L1</sup>=Ti<sup>L2</sup> for i = 0 to n<em> </em>(<a href="ConstantPool.doc.html#78621">&#167;5.3.4</a>).<p>
<a name="71722"></a>
<h4>5.4.3.4    Interface Method Resolution</h4>
<a name="72841"></a>
To resolve an unresolved symbolic reference from D to an interface method in an 
interface C, the symbolic reference to C given by the interface method reference is 
first resolved <a href="ConstantPool.doc.html#71636">(&#167;5.4.3.1)</a>. Therefore, any exceptions that can be thrown as a result of 
failure of resolution of an interface reference can be thrown as a result of failure of 
interface method resolution. If the reference to C can be successfully resolved, 
exceptions relating to the resolution of the interface method reference itself can be 
thrown.
<p><a name="73943"></a>
When resolving an interface method reference:<p>
<ul><li>If C is not an interface, interface method resolution throws an <code>IncompatibleClassChangeError</code>.<p>
<li>Otherwise, if the referenced method does not have the same name and descriptor as a method in C or in one of the superinterfaces of C, or in class <code>Object</code>, interface method resolution throws a <code>NoSuchMethodError</code>.
</ul><a name="77335"></a>
Otherwise, let &lt;E, L1&gt; be the interface in which the referenced interface method is actually declared and let L2 be the defining loader of D. Let T0 be the name of the type returned by the referenced method, and let T1, ..., Tn be the names of the argument types of the referenced method. The Java virtual machine must impose the loading constraints Ti<sup>L1</sup> = Ti<sup>L2</sup> for i = 0 to n<em> </em>(<a href="ConstantPool.doc.html#78621">&#167;5.3.4</a>).<p>
<a name="75929"></a>
<h3>5.4.4    Access Control</h3>
<a name="75931"></a>
A class or interface C is <em>accessible</em> to a class or interface D if and only if either of the 
following conditions are true:
<p><ul><li>C is <code>public</code>.<p>
<li>C and D are members of the same runtime package <a href="ConstantPool.doc.html#72007">(&#167;5.3)</a>.
</ul><a name="75934"></a>
A field or method R is <em>accessible</em> to a class or interface D if and only if any of the 
following conditions is true:
<p><ul><li>R is <code>public</code>.<p>
<li>R is <code>protected</code> and is declared in a class C, and D is either a subclass of C  or C itself.<p>
<li>R is either <code>protected</code> or package private (that is, neither <code>public</code> nor  <code>protected</code> nor <code>private</code>), and is declared by a class in the same runtime  package as D.<p>
<li>R is <code>private</code> and is declared in D.
</ul><a name="78241"></a>
This discussion of access control omits a related restriction on the target of a <code>protected</code> field access or method invocation (the target must be of class D or a subtype of D). That requirement is checked as part of the verification process <a href="ConstantPool.doc.html#71817">(&#167;5.4.1)</a>; it is not part of link-time access control.<p>
<a name="77976"></a>
<hr><h2>5.5    Initialization</h2>
<a name="77978"></a>
<i>Initialization</i> of a class or interface consists of invoking its static initializers 
<a href="Concepts.doc.html#32316">(&#167;2.11)</a> and the initializers for static fields <a href="Concepts.doc.html#16320">(&#167;2.9.2)</a> declared in the class. This process
is described in more detail in <a href="Concepts.doc.html#19075">&#167;2.17.4</a> and <a href="Concepts.doc.html#24237">&#167;2.17.5</a>.
<p><a name="74300"></a>
A class or interface may be initialized only as a result of:<p>
<ul><li>The execution of any one of the Java virtual machine instructions <i>new</i>,  <i>getstatic</i>, <i>putstatic</i>, or <i>invokestatic</i> that references the class or interface. Each of these instructions corresponds to one of the conditions in <a href="Concepts.doc.html#19075">&#167;2.17.4</a>. All of the previously listed instructions reference a class directly or indirectly through either a field reference or a method reference. Upon execution of a <i>new</i>  instruction, the referenced class or interface is initialized if it has not been  initialized already. Upon execution of a <i>getstatic, putstatic, </i>or <i>invokestatic</i> instruction, the class or interface that declared the resolved field or method is initialized if it has not been initialized already.<p>
<li>Invocation of certain reflective methods in the class library (<a href="Overview.doc.html#15641">&#167;3.12</a>), for  example, in class <code>Class </code>or in package <code>java.lang.reflect</code>. <p>
<li>The initialization of one of its subclasses.<p>
<li>Its designation as the initial class at Java virtual machine start-up <a href="ConstantPool.doc.html#51579">(&#167;5.2)</a>.
</ul><a name="74305"></a>
Prior to initialization a class or interface must be linked, that is, verified, prepared, 
and optionally resolved.
<p><a name="74727"></a>
<hr><h2>5.6    Binding Native Method Implementations</h2>
<a name="74730"></a>
<i>Binding</i> is the process by which a function written in a language other than the Java 
programming language and implementing a <code>native</code> method is integrated into the 
Java virtual machine so that it can be executed. Although this process is traditionally 
referred to as linking, the term binding is used in the specification to avoid confusion 
with linking of classes or interfaces by the Java virtual machine.
<p>

<hr>
<sup>1</sup><a name="79448"></a>
 	Since JDK release 1.1 the Java virtual machine invokes the <code>loadClass</code> method of a class loader in order to cause it to load a class or interface. The argument to <code>loadClass</code> is the name of the class or interface to be loaded. There is also a two-argument version of the <code>loadClass</code> method. The second argument is a <code>boolean</code> that indicates whether the class or interface is to be linked or not. Only the two-argument version was supplied in JDK release 1.0.2, and the Java virtual machine relied on it to link the loaded class or interface. From JDK release 1.1 onward, the Java virtual machine links the class or interface directly, without relying on the class loader.<p>
<sup>2</sup><a name="81526"></a>
 <code>UnsupportedClassVersionError</code> was introduced in the Java 2 platform, Standard Edition, v1.2. In earlier versions of the platform an instance of <code>NoClassDefFoundError</code> or <code>ClassFormatError</code> was thrown in case of an unsupported version depending on whether the class was being loaded by the system class loader or a user-defined class loader.<p>
<!-- This inserts footnotes--><p>
<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>
<p>
<font size="-1"><i>The Java</i><sup><font size=-2>TM</font></sup><i> Virtual Machine Specification </i><br>
<!-- HTML generated by Suzette Pelouch on March 30, 1999 -->
<i><a href="Copyright.doc.html">Copyright &#169 1999 Sun Microsystems, Inc.</a>
All rights reserved</i>
<br>
Please send any comments or corrections to <a href="mailto:[e-mail]">[e-mail]</a>
</font>
</body></html>