📄 changesappendix.doc.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><html><head><title>Summary of Clarifications and Amendments </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="Mnemonics.doc.html">Prev</a> | <a href="VMSpecIX.fm.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="449154"></a><h1>Summary of Clarifications and Amendments </h1><hr><p>This appendix discusses the differences between the original version of <i>The Java</i><sup><font size=-2>TM</font></sup><i> Virtual Machine Specification</i> and the present revision. Its purpose is twofold:to summarize what changes have been made and to explain why they were made.<p><a name="447893"></a>Throughout this appendix, we refer to the original version of <i>The Java</i><sup><font size=-2>TM</font></sup><i> Virtual Machine Specification</i> (that is, the first published version of this book) as the <em>original specification</em> or <em>the original specification of the Java virtual machine</em>. We refer to the current book as the <em>revised specification</em>. We denote the first edition of <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i> as simply <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>.<p><a name="445915"></a>The revised specification seeks to clarify points that gave rise to misunderstanding and to correct ambiguities, errors, and omissions in the original specification. <p><a name="447155"></a>Except for the treatment of floating-point computation, the differences between the revised specification and its predecessor have no effect on valid programs written in the Java programming language. The revisions influence only how the virtual machine handles incorrect programs. In many of these instances, most implementations did not implement the original specification. The revised specification documents the intended behavior.<p><a name="445926"></a>The most obvious changes are in the specification of floating-point types and operations; <code>class</code> file verification; initialization, loading, and linking; and the method invocation instructions. In addition, several other important corrections have been made.<p><a name="447989"></a>The revised specification also fixes errors or clarifies issues that were brought to our attention by readers of the original specification.<p><a name="447830"></a>While we have made every effort to correct as many problems as possible, we recognize that additional improvements would benefit this specification. In particular, we believe that the description of <code>class</code> file verification should be further refined, ideally to the point of constituting a formal specification. We anticipate that future revisions will address remaining weaknesses and correct any newly reported bugs, while retaining unchanged the semantics of the Java programming language.<p><a name="447828"></a>The following sections discuss the changes to the original specification in greater detail and explain why the changes were necessary.<p><a name="445929"></a><hr><h2> Floating-Point Types and Operations</h2>The original specification required that all single- and double-precision floating-point calculations round their results to the IEEE 754 single- and double-precision formats, respectively. The revised specification permits additional floating-point calculationsto be done using IEEE 754 extended precision formats. <p><a name="448729"></a>As a result of this change, implementations on processors that more naturally and efficiently support extended precision formats and floating-point operations on extended precision formats can deliver better performance for floating-point calculations. Implementations on processors that naturally and efficiently implement IEEE 754 single- and double-precision operations as mandated by the original specification may continue to do so. The floating-point behavior of any Java virtual machine implementation that conforms to the original specification also conforms to the revised specification. <p><a name="448680"></a><hr><h2> Changes to <font size=+4><code>class</code></font> File Verification</h2>The most important clarification on the topic of <code>class</code> file verification is that every Java virtual machine implementation must in fact perform verification. This is stated unambiguously in the <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>. The original specification of the Java virtual machine contained several misleading sentences that led some readers to conclude that verification was optional. <p><a name="448014"></a>The discussion of the <code>class</code> file format in Chapter 4 also corrects a number of small errors in the original specification. The most significant of these corrections are:<p><ul><li>Interfaces can contain methods other than class or interface initialization methods (<code><clinit></code> methods). <p><li>The class reference in a <code>CONSTANT_Fieldref_info</code> can be an interface type since interfaces can contain <code>static</code> fields. <p><li>Methods that are <code>native</code> or <code>abstract</code> cannot have a <code>Code</code> attribute. <p><li>Multiple declarations of a field or method with the same name and descriptor are illegal.</ul>All of the preceding changes correct misstatements in the original specification that were obviously untrue. In addition, <code>class</code> file verification no longer bans attempts to invoke <code>abstract</code> methods; see a complete discussion of this issue later in this appendix.<p><a name="447244"></a><hr><h2> Initialization</h2><i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i> and the original specification of the Java virtual machine contradict each other on the question of whether the element type of an array type must be initialized when an instance of the array type is created. <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specificatio</i>n specifies that the element type should be initialized in this case, whereas the original specification of the Java virtual machine states that it should not. We have resolved this contradiction in favor of the original Java virtual machine specification. <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i> is thus in error, and will be corrected in its next edition. <p><a name="449271"></a>The evident confusion over the circumstances triggering initialization led us to reword the specification of when initialization occurs (<a href="Concepts.doc.html#19075">§2.17.4</a>). However, this reworded specification is equivalent to the original.<p><a name="447274"></a>One of the original requirements was that a class would be initialized the first time one of its constructors is invoked. In the Java programming language, constructor invocation constitutes instance creation. Furthermore, since no instance method can be invoked if no instances exist, it is clear that the requirement that a class be initialized the first time one of its methods is invoked is relevant only for <code>static</code> methods. By similar reasoning, the requirement that a class be initialized if any of its fields is accessed applies only to <code>static</code> fields.<p><a name="447369"></a>The original specification did not accurately describe the circumstances that would trigger initialization at the Java virtual machine level (see discussion later in this appendix). <a href="ConstantPool.doc.html#77976">Section 5.5</a> now gives a simple and precise definition in terms of Java virtual machine instructions.<p><a name="447321"></a><hr><h2> Loading and Linking</h2>Chapter 5, <a href="ConstantPool.doc.html#67962">"Loading, Linking, and Initializing,"</a> has been completely rewritten (and retitled). Chapter 5 of the original specification was erroneous in several important respects. The new chapter corrects these errors and tries to be both clearer and more precise. The organization of the revised chapter closely follows the structure of the corresponding sections in Chapter 12 of <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>. <p><a name="446365"></a>The key changes include the following:<p><ul><li><em>Clarifying that loading a class causes its superinterfaces to be resolved.</em></ul><ul><p>The description of class loading in the original specification did not state that resolving a class required its superinterfaces to be resolved. This was an error in early Java virtual machine implementations that has been corrected.</p></ul><ul><li><em>Clarifying that resolution does not necessarily imply further linking.</em></ul><ul><p>The description of <code>CONSTANT_Class_info</code> resolution in Section 5.1.1 of the original specification implied that resolution of a reference to a class causes it to be linked. While this was true of Sun's Java virtual machine implementation,the description was more restrictive than <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>, which clearly states that Java virtual machine implementations have flexibility in the timing of linking activities. The revised specification of the Java virtual machine agrees with The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i> on this issue.</i></p></ul><ul><li><em>Clarifying that resolution does not imply initialization.</em></ul><ul><p>The description of <code>CONSTANT_Class_info</code> resolution in Section 5.1.1 of the original specification implied that resolution of a class causes it to be initialized.However, the original specification also included the contradictory statement that initialization should occur only on the first active use of a class. In a Java virtual machine implementation that performs lazy resolution, the distinction is subtle. In other implementations the distinction is much clearer. For example, eager resolution is explicitly allowed by <i>The Java</i><sup></sup><i> Language Specification</i>. If resolution always provoked initialization, such an implementationwould be forced to perform eager initialization, in clear contradiction to <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>. The contradiction is resolved by decouplingresolution from initialization.</p><p>A closely related problem is the statement in Section 5.1.2 of the original specification that the <code>loadClass</code> method of class <code>ClassLoader</code> can cause initialization to occur if its second argument is <code>true</code>. This contradicts <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>, which states that only loading and linking occur in this case. Again, the contradiction has been resolved to conform to <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>, for essentially the same reasons.</p></ul><ul><li><em>Clarifying that class loading uses</em> <code>ClassLoader.loadClass(String)</code>.</ul><ul><p>The original specification stated that when loading a class or interface using a user-defined class loader the Java virtual machine invokes the two-argument method <code>ClassLoader.loadClass(String,</code> <code>boolean)</code>. The purpose of the <code>boolean</code> argument was to indicate whether linking should take place. However,it was noted on page 144 of the original specification that this interface was likely to change. It was recognized that placing responsibility for linking on the class loader was both inappropriate and unreliable. </p><p>Beginning with JDK release 1.1, linking is handled directly by the Java virtual machine. An additional method <code>loadClass(String)</code> has also been added to class <code>ClassLoader</code>. This method may similarly be invoked by the Java virtual machine. The revised specification defines class loading in terms of the new method. The two argument version is still retained in the Java 2 platform v1.2 in the interests of compatibility, but plays no role in the revised specification.</p></ul><ul><li><em>Making explicit requirements for type safe class loading.</em> </ul><ul><p>The subtleties of type safe linkage in the presence of multiple, user-defined class loaders were not sufficiently appreciated when the original specification was written. It has subsequently become clear that a detailed description of loading constraints on runtime types is warranted. Of course, the presence of loading constraints is observable only by invalid programs.</p></ul><ul><li><em>Specifying explicitly the rules for access control. </em></ul><ul><p>These rules follow from <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>, but were left implicit in the original specification. The rules correspond to the behavior of existing implementations.</p></ul><ul><li><em>Indicating that more appropriate exceptions are thrown when a class or interface is invalid.</em></ul><ul><p>Section 5.1.1 of the original specification states that a <code>NoClassDefFoundError</code> should be thrown if the representation of a class or interface is invalid. However, both <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i> and Section 2.16.2 of the original specification state that a <code>ClassFormatError</code> is thrown in this case. Clearly, a <code>ClassFormatError</code> is more appropriate. </p></ul><ul><li><em>Clarifying that the class hierarchy is searched when resolving fields and methods.</em></ul><ul><p>The original specification was unclear as to whether, during method or field resolution, the referenced field had to be declared in the exact class referenced or could be inherited. This led to variations among Java virtual machine implementations and inconsistency between <em>The Java</em><sup></sup><em> Virtual Machine Specification</em> and <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>. The revised specification gives a more precise description that agrees with the behavior of most implementations, but not with <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i>. <i>The Java</i><sup><font size=-2>TM</font></sup><i> Language Specification</i> will be corrected in its next edition.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -