13.4.17

native

Methods

BINARY COMPATIBILITY

Removing the

final

 modifier from a method does not break compatibility

with pre existing binaries.

13.4.17

native

Methods

Adding or deleting a

native

 modifier of a method does not break compatibility

with pre existing binaries.

The impact of changes to Java types on preexisting

native

 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 encour 

aged, but not required, to implement

native

 methods in a way that limits such

impact.

13.4.18

static

Methods

If a method that is not declared

private

 was declared

static

 (that is, a class

method) and is changed to not be declared

static

 (that is, to an instance method),

or vice versa, then compatibility with pre existing binaries may be broken, result 

ing in a linkage time error, namely an

IncompatibleClassChangeError

, if these

methods are used by the pre existing binaries. Such changes are not recommended

in code that has been widely distributed.

13.4.19

synchronized

Methods

Adding or deleting a

synchronized

 modifier of a method does not break compat 

ibility with existing binaries.

13.4.20   Method and Constructor Throws

Changes to the

throws

 clause of methods or constructors do not break compati 

bility with existing binaries; these clauses are checked only at compile time.

We are considering whether a future version of the Java language should

require more rigorous checking of

throws

 clauses when classes are verified.

13.4.21   Method and Constructor Body

Changes to the body of a method or constructor do not break compatibility with

pre existing binaries.

We note that a compiler cannot inline expand a method at compile time

unless, for example, either:

256