13.doc.html

java语言规范

Changing a class (<code>static</code>) method that is not <code>final</code> to be <code>final</code> does not break compatibility with existing binaries, because the class of the actual method to be invoked is resolved at compile time.<p>
<a name="45254"></a>
Removing the <code>final</code> modifier from a method does not break compatibility with pre-existing binaries.<p>
<a name="45255"></a>
<h3>13.4.17    <code>native</code> Methods</h3>
<a name="45256"></a>
Adding or deleting a <code>native</code> modifier of a method does not break compatibility 
with pre-existing binaries.
<p><a name="46194"></a>
The impact of changes to Java types on preexisting <code>native</code> methods that are not recompiled is beyond the scope of this specification and should be provided with the description of an implementation of Java. Implementations are encouraged, but not required, to implement <code>native</code> methods in a way that limits such impact.<p>
<a name="45257"></a>
<h3>13.4.18    <code>static</code> Methods</h3>
<a name="45258"></a>
If a method that is not declared <code>private</code> was declared <code>static</code> (that is, a class 
method) and is changed to not be declared <code>static</code> (that is, to an instance method), 
or vice versa, then compatibility with pre-existing binaries may be broken, resulting
in a linkage time error, namely an <code>IncompatibleClassChangeError</code>, if these 
methods are used by the pre-existing binaries. Such changes are not recommended 
in code that has been widely distributed.
<p><a name="45259"></a>
<h3>13.4.19    <code>synchronized</code> Methods</h3>
<a name="45260"></a>
Adding or deleting a <code>synchronized</code> modifier of a method does not break compatibility
with existing binaries.
<p><a name="45262"></a>
<h3>13.4.20    Method and Constructor Throws</h3>
<a name="45263"></a>
Changes to the <code>throws</code> clause of methods or constructors do not break compatibility
with existing binaries; these clauses are checked only at compile time.
<p><a name="45264"></a>
We are considering whether a future version of the Java language should require more rigorous checking of <code>throws</code> clauses when classes are verified.<p>
<a name="45265"></a>
<h3>13.4.21    Method and Constructor Body</h3>
<a name="45266"></a>
Changes to the body of a method or constructor do not break compatibility with 
pre-existing binaries.
<p><a name="45267"></a>
We note that a compiler cannot inline expand a method at compile time unless, for example, either:<p>
<ul><a name="45268"></a>
<li>the method is <code>private</code> to its class
<a name="45269"></a>
<li>an entire package is guaranteed to be kept together and the method is accessible only within that package
<a name="45270"></a>
<li>a set of Java code is being compiled to a special binary format where the specified method is available only within a binary or set of binaries which are being kept together.
</ul><a name="45271"></a>
The keyword <code>final</code> on a method does not mean that the method can be safely 
inlined; it only means that the method cannot be overridden. Unless the compiler 
has extraordinary knowledge, it is still possible that a new version of that method 
will be provided at link time.
<p><a name="45272"></a>
In general we suggest that Java implementations use late-bound (run-time) code generation and optimization.<p>
<a name="45274"></a>
<h3>13.4.22    Method and Constructor Overloading</h3>
<a name="45275"></a>
Adding new methods that overload existing method names does not break compatibility
with pre-existing binaries. The method signature to be used for each 
method invocation was determined when these existing binaries were compiled; 
therefore newly added methods will not be used, even if their signatures are both 
applicable and more specific than the method signature originally chosen.
<p><a name="45276"></a>
While adding a new overloaded method or constructor may cause a compile-time error the next time a class or interface is compiled because there is no method or constructor that is most specific <a href="15.doc.html#18428">(&#167;15.11.2.2)</a>, no such error occurs when a Java program is executed, because no overload resolution is done at execution time.<p>
<a name="45280"></a>
If the example program:<p>
<pre><a name="45281"></a>
class Super {
<a name="45282"></a>	static void out(float f) { System.out.println("float"); }
<a name="45283"></a>}
<a name="45284"></a>
class Test {
<a name="45285"></a>	public static void main(String[] args) {
<a name="45286"></a>		Super.out(2);
<a name="45287"></a>	}
<a name="45288"></a>}
</pre><a name="45289"></a>
is compiled and executed, it produces the output:
<p><pre><a name="45290"></a>float
</pre><a name="45291"></a>
Suppose that a new version of class <code>Super</code> is produced:
<p><pre><a name="45292"></a>
class Super {
<a name="45293"></a>	static void out(float f) { System.out.println("float"); }
<a name="45294"></a>	static void out(int i) { System.out.println("int"); }
<a name="45295"></a>}
</pre><a name="45296"></a>
If <code>Super</code> is recompiled but not <code>Test</code>, then running the new binary with the existing
binary of <code>Test</code> still produces the output:
<p><pre><a name="45297"></a>float
</pre><a name="45298"></a>
However, if <code>Test</code> is then recompiled, using this new <code>Super</code>, the output is then:
<p><pre><a name="45299"></a>int
</pre><a name="45300"></a>
as might have been naively expected in the previous case.
<p><a name="45301"></a>
<h3>13.4.23    Method Overriding</h3>
<a name="45302"></a>
If an instance method is added to a subclass and it overrides a method in a superclass,
then the subclass method will be found by method invocations in pre-existing
binaries, and these binaries are not impacted. If a class method is added to a 
class, then this method will not be found, because the invocation of a class method 
is resolved at compile time to use the fully qualified name of the class where the 
method is declared. Thus if the example:
<p><pre><a name="45303"></a>
class Hyper {
<a name="45304"></a>	void hello() { System.out.print("Hello, "); }
<a name="45305"></a>	static void world() { System.out.println("world!"); }
<a name="45306"></a>}
<a name="45307"></a>class Super extends Hyper { }
<a name="45308"></a>
class Test {
<a name="45309"></a>	public static void main(String[] args) {
<a name="45310"></a>		Super s = new Super();
<a name="45311"></a>		s.hello();
<a name="45312"></a>		s.world();
<a name="45313"></a>	}
<a name="45314"></a>}
</pre><a name="45315"></a>
is compiled and executed, it produces the output:
<p><pre><a name="45316"></a>Hello, world!
</pre><a name="45317"></a>
Suppose that a new version of class <code>Super</code> is produced:
<p><pre><a name="45318"></a>
class Super extends Hyper {
<a name="45319"></a>	void hello() { System.out.print("Goodbye, cruel "); }
<a name="45320"></a>	static void world() { System.out.println("earth!"); }
<a name="45321"></a>}
</pre><a name="45322"></a>
If <code>Super</code> is recompiled but not <code>Hyper</code> or <code>Test</code>, then running the new binary with 
the existing binaries for <code>Hyper</code> and <code>Test</code> will produce the output:
<p><pre><a name="45323"></a>Goodbye, cruel world!
</pre><a name="45324"></a>
This example demonstrates that the invocation in:
<p><pre><a name="45325"></a>s.world();
</pre><a name="45326"></a>
in the method <code>main</code> is resolved, at compile time, to a symbolic reference to the 
class containing the class method <code>world</code>, as though it had been written:
<p><pre><a name="45327"></a>Hyper.world();
</pre><a name="45328"></a>
This is why the <code>world</code> method of <code>Hyper</code> rather than <code>Super</code> is invoked in this 
example. Of course, recompiling all the classes to produce new binaries will allow 
the output:
<p><pre><a name="45329"></a>Goodbye, cruel earth!
</pre><a name="45330"></a>
to be produced.
<p><a name="45331"></a>
<h3>13.4.24    Static Initializers</h3>
<a name="45335"></a>
Adding, deleting, or changing a static initializer <a href="8.doc.html#39245">(&#167;8.5)</a> of a class does not impact 
pre-existing binaries.
<p><a name="45337"></a>
<h2>13.5    Evolution of Interfaces</h2>
<a name="45338"></a>
This section describes the impact of changes to the declaration of an interface and 
its members on pre-existing binaries.
<p><a name="45339"></a>
<h3>13.5.1    <code>public</code> Interfaces</h3>
<a name="45340"></a>
Changing an interface that is not declared <code>public</code> to be declared <code>public</code> does not 
break compatibility with pre-existing binaries.
<p><a name="45341"></a>
If an interface that is declared <code>public</code> is changed to not be declared <code>public</code>, then an <code>IllegalAccessError</code> is thrown if a pre-existing binary is linked that needs but no longer has access to the interface type, so such a change is not recommended for widely distributed interfaces.<p>
<a name="45342"></a>
<h3>13.5.2    Superinterfaces</h3>
<a name="45343"></a>
Changes to the interface hierarchy cause errors in the same way that changes to 
the class hierarchy do, as described in <a href="13.doc.html#44994">&#167;13.4.4</a>. In particular, changes that result in 
any previous superinterface of a class no longer being a superinterface can break 
compatibility with pre-existing binaries, resulting in a <code>VerifyError</code>.
<p><a name="45347"></a>
<h3>13.5.3    The Interface Members</h3>
<a name="45348"></a>
Adding a member to an interface does not break compatibility with pre-existing 
binaries.
<p><a name="45349"></a>
Deleting a member from an interface may cause linkage errors in pre-existing binaries. If the example program:<p>
<pre><a name="45350"></a>interface I { void hello(); }
<a name="45351"></a>class Test implements I {
</pre><pre><a name="45352"></a>
	public static void main(String[] args) {
<a name="45353"></a>		I anI = new Test();
<a name="45354"></a>		anI.hello();
<a name="45355"></a>	}
<a name="45356"></a>	public void hello() { System.out.println("hello"); }
<a name="45357"></a>}
</pre><a name="45358"></a>
is compiled and executed, it produces the output:
<p><pre><a name="45359"></a>hello
</pre><a name="45360"></a>
Suppose that a new version of interface <code>I</code> is compiled:
<p><pre><a name="45361"></a>interface I { }
</pre><a name="45362"></a>
If <code>I</code> is recompiled but not <code>Test</code>, then running the new binary with the existing 
binary for <code>Test</code> will result in a <code>NoSuchMethodError</code>. (In some early implementations
of Java this program still executed; the fact that the method <code>hello</code> no longer 
exists in interface <code>I</code> was not correctly detected.)
<p><a name="45363"></a>
<h3>13.5.4    Field Declarations</h3>
<a name="45364"></a>
The considerations for changing field declarations in interfaces are the same as 
those for <code>static</code> <code>final</code> fields in classes, as described in <a href="13.doc.html#45118">&#167;13.4.7</a> and <a href="13.doc.html#45139">&#167;13.4.8</a>.
<p><a name="45371"></a>
<h3>13.5.5    Abstract Method Declarations</h3>
<a name="46514"></a>
The considerations for changing abstract method declarations in interfaces are the 
same as those for <code>abstract</code> methods in classes, as described in <a href="13.doc.html#45202">&#167;13.4.13</a>, 
<a href="13.doc.html#45208">&#167;13.4.14</a>, <a href="13.doc.html#45262">&#167;13.4.20</a>, and <a href="13.doc.html#45274">&#167;13.4.22</a>.
<p><a name="55303"></a>
<p>


<hr>
<!-- This inserts footnotes--><p>
<a href="index.html">Contents</a> | <a href="12.doc.html">Prev</a> | <a href="14.doc.html">Next</a> | <a href="j.index.doc1.html">Index</a>
<p>
<font size=-1>Java Language Specification (HTML generated by Suzette Pelouch on February 24, 1998)<br>
<i><a href="jcopyright.doc.html">Copyright &#169 1996 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>