12.doc.html

java语言规范

<a name="44492"></a>
<i>Verification</i> ensures that the binary representation of a class or interface is structurally
correct. For example, it checks that every instruction has a valid operation 
code; that every branch instruction branches to the start of some other instruction, 
rather than into the middle of an instruction; that every method is provided with a 
structurally correct signature; and that every instruction obeys the type discipline 
of the Java language.
<p><a name="44493"></a>
For a more detailed description of the verification process, see the separate volume of this series, <i>The Java Virtual Machine Specification</i>.<p>
<a name="44494"></a>
If an error occurs during verification, then an instance of the following subclass of class <code>LinkageError</code> will be thrown at the point in the Java program that caused the class to be verified:<p>
<ul><a name="47964"></a>
<li><code>VerifyError</code>: The binary definition for a class or interface failed to pass a set of required checks to verify that it obeys the semantics of the Java language and that it cannot violate the integrity of the Java Virtual Machine. (See <a href="13.doc.html#44987">&#167;13.4.2</a>, <a href="13.doc.html#44994">&#167;13.4.4</a>, <a href="13.doc.html#45139">&#167;13.4.8</a>, and <a href="13.doc.html#45238">&#167;13.4.16</a> for some examples.)
</ul><a name="47979"></a>
<h3>12.3.2    Preparation of a Class or Interface Type</h3>
<a name="44510"></a>
<i>Preparation</i> involves creating the <code>static</code> fields (class variables and constants) for 
a class or interface and initializing such fields to the standard default values 
<a href="4.doc.html#10931">(&#167;4.5.4)</a>. This does not require the execution of any Java code; explicit initializers 
for <code>static</code> fields are executed as part of initialization <a href="12.doc.html#44557">(&#167;12.4)</a>, not preparation.
<p><a name="46216"></a>
Java implementations must detect the following error during preparation:<p>
<ul><a name="46217"></a>
<li><code>AbstractMethodError</code>: A class that is not declared to be <code>abstract</code> has an <code>abstract</code> method. This can occur, for example, if a method that is originally not <code>abstract</code> is changed to be <code>abstract</code> after another class that inherits the now <code>abstract</code> method declaration has been compiled <a href="13.doc.html#45214">(&#167;13.4.15)</a>.
</ul><a name="46228"></a>
If such an error is detected, then an instance of <code>AbstractMethodError</code> should be 
thrown at the point in the Java program that caused the class to be prepared.
<p><a name="46239"></a>
Implementations of the Java Virtual Machine may precompute additional data structures at preparation time in order to make later operations on a class or interface more efficient. One particularly useful data structure is a "method table" or other data structure that allows any method to be invoked on instances of a class without requiring a search of superclasses at invocation time.<p>
<a name="44524"></a>
<h3>12.3.3    Resolution of Symbolic References</h3>
<a name="44525"></a>
A Java binary file references other classes and interfaces and their fields, methods, 
and constructors symbolically, using the fully-qualified names of the other classes 
and interfaces <a href="13.doc.html#44909">(&#167;13.1)</a>. For fields and methods, these symbolic references include 
the name of the class or interface type that declares the field or method as well as 
the name of the field or method itself, together with appropriate type information.
<p><a name="44529"></a>
Before a symbolic reference can be used it must be undergo <i>resolution</i>, wherein a symbolic reference is checked to be correct and, typically, replaced with a direct reference that can be more efficiently processed if the reference is used repeatedly.<p>
<a name="44530"></a>
If an error occurs during resolution, then an error will be thrown. Most typically, this will be an instance of one of the following subclasses of the class <code>IncompatibleClassChangeError</code>, but it may also be an instance of some other subclass of <code>IncompatibleClassChangeError</code> or even an instance of the class <code>IncompatibleClassChangeError</code> itself. This error may be thrown at any point in the program that uses a symbolic reference to the type, directly or indirectly:<p>
<ul><a name="44531"></a>
<li><code>IllegalAccessError</code>: A symbolic reference has been encountered that specifies a use or assignment of a field, or invocation of a method, or creation of an instance of a class, to which the code containing the reference does not have access because the field or method was declared <code>private</code>, <code>protected</code>, or default access (not <code>public</code>), or because the class was not declared <code>public</code>. This can occur, for example, if a field that is originally declared <code>public</code> is changed to be <code>private</code> after another class that refers to the field has been compiled <a href="13.doc.html#47259">(&#167;13.4.6)</a>.
<a name="44535"></a>
<li><code>InstantiationError</code>: A symbolic reference has been encountered that is used in a class instance creation expression, but an instance cannot be created because the reference turns out to refer to an interface or to an <code>abstract</code> class. This can occur, for example, if a class that is originally not <code>abstract</code> is changed to be <code>abstract</code> after another class that refers to the class in question has been compiled <a href="13.doc.html#44980">(&#167;13.4.1)</a>.
<a name="44539"></a>
<li><code>NoSuchFieldError</code>: A symbolic reference has been encountered that refers to a specific field of a specific class or interface, but the class or interface does not declare a field of that name (it is specifically not sufficient for it simply to be an inherited field of that class or interface). This can occur, for example, if a field declaration was deleted from a class after another class that refers to the field was compiled <a href="13.doc.html#45118">(&#167;13.4.7)</a>.
<a name="44543"></a>
<li><code>NoSuchMethodError</code>: A symbolic reference has been encountered that refers to a specific method of a specific class or interface, but the class or interface does not declare a method of that signature (it is specifically not sufficient for it simply to be an inherited method of that class or interface). This can occur, for example, if a method declaration was deleted from a class after another class that refers to the method was compiled <a href="13.doc.html#45197">(&#167;13.4.12)</a>.
</ul><a name="49761"></a>
Additionally, an <code>UnsatisfiedLinkError</code> (a subclass of <code>LinkageError</code>) may be thrown if a class declares a <code>native</code> method for which no implementation can be found. The error will occur if the method is used, or earlier depending on what kind of resolution strategy is being used by the virtual machine <a href="12.doc.html#44487">(&#167;12.3)</a>.<p>
<a name="44547"></a>
<h3>12.3.4    Linking: Implications for Code Generation</h3>
<a name="44548"></a>
The symbolic references within a group of types may be resolved even before the 
group is loaded <a href="12.doc.html#44484">(&#167;12.2.2)</a>, in an implementation that uses a special (non-standard) 
binary format <a href="13.doc.html#44909">(&#167;13.1)</a>. This corresponds to the traditional practice of "linkage 
editing." Even if this is not done, a Java implementation has a lot of flexibility. It 
may resolve all symbolic references from a type at the point of the first linkage 
activity on the type, or defer the resolution of each symbolic reference to the first 
use of that reference.
<p><a name="44555"></a>
We note that the flexibility accorded the Java implementation in the linkage process does not affect correctly formed Java programs, which should never encounter linkage errors.<p>
<a name="44557"></a>
<h2>12.4    Initialization of Classes and Interfaces</h2>
<a name="44558"></a>
Initialization of a class consists of executing its static initializers and the initializers
for <code>static</code> fields (class variables) declared in the class. Initialization of an 
interface consists of executing the initializers for fields (constants) declared there.
<p><a name="47219"></a>
Before a class is initialized, its superclass must be initialized, but interfaces implemented by the class need not be initialized. Similarly, the superinterfaces of an interface need not be initialized before the interface is initialized.<p>
<a name="44560"></a>
<h3>12.4.1    When Initialization Occurs</h3>
<a name="44561"></a>
A class or interface type <i>T</i> will be <i>initialized</i> at its first <i>active use</i>, which occurs if:
<p><ul><a name="44562"></a>
<li><i>T</i> is a class and a method actually declared in <i>T</i> (rather than inherited from a superclass) is invoked.
<a name="44563"></a>
<li><i>T</i> is a class and a constructor for class <i>T</i> is invoked, or <i>U</i> is an array with element type <i>T</i>, and an array of type <i>U</i> is created.
<a name="44564"></a>
<li>A non-constant field declared in <i>T</i> (rather than inherited from a superclass or superinterface) is used or assigned. A <i>constant field</i> is one that is (explicitly or implicitly) both <code>final</code> and <code>static</code>, and that is initialized with the value of a compile-time constant expression <a href="15.doc.html#5313">(&#167;15.27)</a>. Java specifies that a reference to a constant field must be resolved at compile time to a copy of the compile-time constant value, so uses of such a field are never active uses. See <a href="13.doc.html#45139">&#167;13.4.8</a> for a further discussion.
</ul><a name="44568"></a>
All other uses of a type are <i>passive uses</i>.
<p><a name="46862"></a>
The intent here is that a class or interface type has a set of initializers that put it in a consistent state, and that this state is the first state that is observed by other classes. The static initializers and class variable initializers are executed in textual order, and may not refer to class variables declared in the class whose declarations appear textually after the use, even though these class variables are in scope <a href="8.doc.html#39245">(&#167;8.5)</a>. This restriction is designed to detect, at compile time, most circular or otherwise malformed initializations. &#32;<p>
<a name="46874"></a>
As shown in an example in <a href="8.doc.html#39245">&#167;8.5</a>, the fact that initialization code is unrestricted allows examples to be constructed where the value of a class variable can be observed when it still has its initial default value, before its initializing expression is evaluated, but such examples are rare in practice. (Such examples can be also constructed for instance variable initialization; see the example at the end of <a href="12.doc.html#44670">&#167;12.5</a>). Java provides the full power of the language in these initializers; programmers must exercise some care. This power places an extra burden on code generators, but this burden would arise in any case because Java is concurrent <a href="12.doc.html#44667">(&#167;12.4.3)</a>.<p>
<a name="44569"></a>
Before a class is initialized, its superclasses are initialized, if they have not previously been initialized.<p>
<a name="44570"></a>
Thus, the test program:<p>
<pre><a name="44571"></a>
class Super {
<a name="44572"></a>	static { System.out.print("Super "); }
<a name="44573"></a>}
<a name="44574"></a>
class One {
<a name="44575"></a>	static { System.out.print("One "); }
<a name="44576"></a>}
<a name="44577"></a>
class Two extends Super {
<a name="44578"></a>	static { System.out.print("Two "); }
<a name="44579"></a>}
<a name="44580"></a>
class Test {
<a name="44581"></a>	public static void main(String[] args) {
<a name="44582"></a>		One o = null;
<a name="44583"></a>		Two t = new Two();
<a name="44584"></a>		System.out.println((Object)o == (Object)t);
<a name="44585"></a>	}
<a name="44586"></a>}
</pre><a name="44587"></a>
prints:
<p><pre><a name="44588"></a>Super Two false
</pre><a name="44589"></a>
The class <code>One</code> is never initialized, because it not used actively and therefore is 
never linked to. The class <code>Two</code> is initialized only after its superclass <code>Super</code> has 
been initialized.
<p><a name="44590"></a>
A reference to a field is an active use of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface. The test program:<p>
<pre><a name="44591"></a>
class Super { static int taxi = 1729; }
<a name="44592"></a>
class Sub extends Super {
<a name="44593"></a>	static { System.out.print("Sub "); }
<a name="44594"></a>}
<a name="44595"></a>
class Test {
<a name="44596"></a>	public static void main(String[] args) {
<a name="44597"></a>		System.out.println(Sub.taxi);
<a name="44598"></a>	}
<a name="44599"></a>}
</pre><a name="44600"></a>
prints only:
<p><pre><a name="44601"></a>1729
</pre><a name="44602"></a>
because the class <code>Sub</code> is never initialized; the reference to <code>Sub.taxi</code> is a reference 
to a field actually declared in class <code>Super</code> and is not an active use of the class <code>Sub</code>.
<p><a name="44603"></a>
Initialization of an interface does not, of itself, require initialization of any of its superinterfaces. Thus, the test program:<p>
<pre><a name="44604"></a>
interface I {
<a name="44605"></a>	int i = 1, ii = Test.out("ii", 2);
<a name="44606"></a>}
<a name="44607"></a>
interface J extends I {
<a name="44608"></a>	int j = Test.out("j", 3), jj = Test.out("jj", 4);
<a name="44609"></a>}
<a name="44610"></a>
interface K extends J {
<a name="44611"></a>	int k = Test.out("k", 5);
<a name="44612"></a>}
<a name="44613"></a>
class Test {
<a name="44614"></a>
	public static void main(String[] args) {