第13章 バイナリ互換性

abstractが宣言されていないクラスがabstractとして宣言されるように変更された場合、そのクラスの新しいインスタンスを作成しようとする既存のバイナリは、リンク時にInstantiationErrorをスローするか、または(リフレクティブ・メソッドが使用されている場合)実行時にInstantiationExceptionをスローします。したがって、このような変更は、広く分散されているクラスにはお薦めしません。

abstractとして宣言されているクラスをabstractとして宣言しないように変更しても、既存のバイナリとの互換性は損なわれません。

publicを宣言されていないクラスをpublicとして変更しても、既存のバイナリとの互換性は損なわれません。

publicとして宣言されたクラスがpublicとして宣言されないように変更された場合、既存のバイナリがリンクされていて、そのクラス・タイプにアクセスできなくなった場合は、IllegalAccessErrorがスローされます。このような変更は、広く分散されているクラスにはお薦めしません。

クラスが自身のスーパークラスである場合、ロード時にClassCircularityErrorがスローされます。 新しくコンパイルされたバイナリが既存のバイナリとともにロードされた場合に、そのような循環を引き起こす可能性があるクラス階層を変更することは、広く分散されたクラスにはお薦めしません。

クラスの直接スーパークラス・タイプまたは直接スーパーインタフェース・タイプのセットを変更しても、クラスのスーパークラスまたはスーパーインタフェースの合計セットがメンバーを失わないかぎり、既存のバイナリとの互換性は損なわれません。

たとえば、クラスのRAWスーパータイプを、RAW型で指定されたクラスまたはインタフェースのパラメータ化に置き換えることは、バイナリ互換性があります。

直接スーパークラスまたは直接スーパー・インタフェースのセットを変更した結果、いずれかのクラスまたはインタフェースがスーパークラスまたはスーパー・インタフェースでなくなった場合、変更されたクラスのバイナリとともに既存のバイナリがロードされると、リンケージ・エラーが発生する可能性があります。 このような変更は、広範囲に分散されたクラスにはお薦めしません。

class Hyper { char h = 'h'; }
class Super extends Hyper { char s = 's'; }
class Test extends Super {
    public static void printH(Hyper h) {
        System.out.println(h.h);
    }
    public static void main(String[] args) {
        printH(new Super());
    }
}

h

class Super { char s = 's'; }

s

try {
    failByThrowingAorB();
} catch (A|B e) {
    ...
}

クラスの型パラメータを追加または削除しても、それ自体はバイナリ互換性には影響しません。

このような型パラメータがフィールドまたはメソッドの型で使用されている場合、前述の型の変更には通常の意味がある可能性があります。

クラスの型パラメータの名前を変更しても、既存のバイナリには影響しません。

クラスの型パラメータの最初の境界を変更すると、その型パラメータを独自の型で使用しているメンバーの消去(§4.6)が変更され、バイナリ互換性に影響する可能性があります。 このようなバインドの変更は、メソッドまたはコンストラクタの型パラメータの最初のバインドの変更に類似しています(§13.4.13)。

他のバインドを変更しても、バイナリ互換性には影響しません。

既存のバイナリとの非互換性は、スーパークラスまたはサブクラスのインスタンス(それぞれstatic)メンバーとして、名前とアクセシビリティ(フィールドの場合)が同じインスタンス(それぞれstatic)メンバー、または名前とアクセシビリティおよびシグネチャと戻り型(メソッドの場合)が同じインスタンス(それぞれstatic)メンバーを追加することで発生しません。 リンクされるクラスのセットでコンパイル時エラーが発生しても、エラーは発生しません。

privateが宣言されていないクラス・メンバーまたはコンストラクタを削除すると、そのメンバーまたはコンストラクタが既存のバイナリによって使用されている場合、リンケージ・エラーが発生する可能性があります。

class Hyper {
    void hello() { System.out.println("hello from Hyper"); }
}
class Super extends Hyper {
    void hello() { System.out.println("hello from Super"); }
}
class Test {
    public static void main(String[] args) {
        new Super().hello();
    }
}

hello from Super

class Super extends Hyper {}

hello from Hyper

superキーワードを使用して、スーパークラスで宣言されたメソッドにアクセスし、現在のクラスで宣言されたメソッドをバイパスできます。 式super.Identifierは、コンパイル時にスーパークラスSのメソッドmに解決されます。 メソッドmがインスタンス・メソッドの場合、実行時に呼び出されるメソッドは、superを含む式を含むクラスの直接スーパークラスのメンバーであるmと同じシグネチャを持つメソッドです。

class Hyper {
    void hello() { System.out.println("hello from Hyper"); }
}
class Super extends Hyper { }
class Test extends Super {
    public static void main(String[] args) {
        new Test().hello();
    }
    void hello() {
        super.hello();
    }
}

hello from Hyper

class Super extends Hyper {
    void hello() { System.out.println("hello from Super"); }
}

hello from Super

メンバーまたはコンストラクタの宣言されたアクセスを、より少ないアクセスを許可するように変更すると、既存のバイナリとの互換性が損なわれる可能性があるため、これらのバイナリが解決されたときにリンケージ・エラーがスローされます。 アクセス修飾子をパッケージ・アクセスからprivateアクセスに変更した場合、protectedアクセスからパッケージ・アクセスまたはprivateアクセスに変更した場合、またはpublicアクセスからprotectedアクセス、パッケージ・アクセスまたはprivateアクセスに変更した場合、アクセスは少なくなります。 したがって、広く分散されているクラスでは、アクセスを制限しないようにメンバーまたはコンストラクタを変更することはお薦めしません。

驚くことに、サブクラス(すでに)がアクセスの少ないメソッドを定義しているときに、メンバーまたはコンストラクタをよりアクセスしやすいように変更してもリンク・エラーが発生しないようにバイナリ形式が定義されています。

package points;
public class Point {
    public int x, y;
    protected void print() {
        System.out.println("(" + x + "," + y + ")");
    }
}

class Test extends points.Point {
    public static void main(String[] args) {
        Test t = new Test();
        t.print();
    }
    protected void print() {
        System.out.println("Test");
    }
}

Test

既存のサブクラスのバイナリを分割せずに、スーパークラスがprotectedメソッドをpublicに変更できるようにすると、バイナリの脆弱性が低下します。 そのような変更によってリンケージエラーが発生する可能性がある代替方法では、追加のバイナリ非互換性が作成されます。

広範に配布されるプログラムがフィールドをそのクライアントに公開しないようにしてください。 これは、前述のバイナリ互換性の問題とは別の、一般的に推奨されるソフトウェア・エンジニアリングの慣例です。 クラスにフィールドを追加すると、再コンパイルされていない既存のバイナリとの互換性が損なわれる可能性があります。

修飾クラスCを持つフィールドfへの参照を想定します。 さらに、fが実際にC、Sのスーパークラスで宣言されたインスタンス(それぞれstatic)フィールドであり、fのタイプがXであるとします。

Cまたは C自体のスーパークラスである Sのサブクラスに、fと同じ名前を持つ X型の新しいフィールドが追加されると、リンクエラーが発生する可能性があります。 そのようなリンク・エラーは、前述以外では、次のいずれかが当てはまる場合のみ発生します。

特に、フィールド・アクセスが、互換性のない型を持つスーパークラスのフィールドを以前に参照していたため、クラスを再コンパイルできなくなった場合は、リンク・エラーは発生しません。 そのような参照がある、以前にコンパイルされたクラスは、引き続きスーパークラスで宣言されたフィールドを参照します。

class Hyper { String h = "hyper"; }
class Super extends Hyper { String s = "super"; }
class Test {
    public static void main(String[] args) {
        System.out.println(new Super().h);
    }
}

hyper

class Super extends Hyper {
    String s = "super";
    int h = 0;
}

hyper

class Hyper { String h = "Hyper"; }
class Super extends Hyper { }
class Test extends Super {
    public static void main(String[] args) {
        String s = new Test().h;
        System.out.println(s);
    }
}

Hyper

class Super extends Hyper { char h = 'h'; }

Hyper

class Hyper { String h = "Hyper"; }
class Super extends Hyper { char h = 'h'; }
class Test extends Super {
    public static void main(String[] args) {
        String s = new Test().h;
        System.out.println(s);
    }
}

クラスからフィールドを削除すると、このフィールドを参照する既存のバイナリとの互換性が損なわれ、既存のバイナリからのそのような参照がリンクされると、NoSuchFieldErrorがスローされます。 広く分散されているクラスから安全に削除できるのは、privateフィールドのみです。

バイナリ互換性のため、型変数(§4.4)またはパラメータ化された型(§4.5)を含むフィールドfを追加または削除することは、型がf型の消去(§4.6)である同じ名前のフィールドの追加(それぞれ削除)と同等です。

finalが宣言されていないフィールドをfinalとして宣言するように変更すると、既存のバイナリとの互換性が損なわれ、フィールドに新しい値を割り当てようとする可能性があります。

class Super { char s; }
class Test extends Super {
    public static void main(String[] args) {
        Super x = new Super();
        x.s = 'a';
        System.out.println(x.s);
    }
}

a

class Super { final char s = 'b'; }

キーワードfinalを削除するか、フィールドの初期化先の値を変更しても、既存のバイナリとの互換性は損なわれません。

フィールドが定数変数(§4.12.4)で、さらにstaticの場合、キーワードfinalを削除するか、その値を変更しても、既存のバイナリとの互換性は損なわれず、実行されませんが、再コンパイルされないかぎり、フィールドの使用に関する新しい値は表示されません。 この結果は、条件付きコンパイルをサポートするという決定の副作用です(§14.22)。 (新しい値は、定数の式(§15.29)で使用が行われた場合には見られず、それ以外の場合は見られたと仮定できます。 これはそうではありません。既存のバイナリには新しい値はまったく表示されません。)

広く配布されるコードで「不定数」の問題を回避する最善の方法は、static定数変数を、実際に変更される可能性が低い値に対してのみ使用することです。 真の数学的定数以外に、ソース・コードではstatic定数変数を非常にスペアリングに使用することをお薦めします。

private static int N;
public static int getN() { return N; }

public static final int N = ...;

public static int N = ...;

privateが宣言されていないフィールドがstaticとして宣言されておらず、staticとして宣言されるように変更された場合(またはその逆の場合)、リンケージ・エラー(特にIncompatibleClassChangeError)は、そのフィールドが、他の種類のフィールドを想定した既存のバイナリによって使用された場合に発生します。 このような変更は、広く配布されているコードではお薦めしません。

フィールドのtransient修飾子を追加または削除しても、既存のバイナリとの互換性は損なわれません。

メソッドまたはコンストラクタをクラスに追加すると、既存のバイナリとの互換性が損なわれることはありません。ただし、呼出しで、互換性のない型を持つスーパークラスのメソッドまたはコンストラクタが以前に参照されていたため、クラスを再コンパイルできなくなった場合です。 そのような参照がある、以前にコンパイルされたクラスは、引き続きスーパークラスで宣言されたメソッドまたはコンストラクタを参照します。

修飾クラスCを持つメソッドmへの参照を想定します。 さらに、mは、実際にはC (S)のスーパークラスで宣言されたインスタンス(それぞれstatic)メソッドであるとします。

mと同じシグネチャおよび戻り型を持つX型の新しいメソッドが、CまたはC自体のスーパークラスであるSのサブクラスに追加されると、リンク・エラーが発生する可能性があります。 そのようなリンク・エラーは、前述以外では、次のいずれかが当てはまる場合のみ発生します。

クラスからメソッドまたはコンストラクタを削除すると、このメソッドまたはコンストラクタを参照する既存のバイナリとの互換性が損なわれる可能性があります。既存のバイナリからの参照がリンクされている場合は、NoSuchMethodErrorがスローされます。 このようなエラーは、一致するシグネチャおよび戻り型を持つメソッドがスーパークラスで宣言されていない場合にのみ発生します。

非内部クラスのソース・コードに宣言されたコンストラクタが含まれていない場合、パラメータのないデフォルト・コンストラクタが暗黙的に宣言されます(§8.8.9)。 このようなクラスのソース・コードに1つ以上のコンストラクタ宣言を追加すると、このデフォルト・コンストラクタが暗黙的に宣言されるのを防ぎ、新しいコンストラクタの1つにもパラメータがないため、デフォルト・コンストラクタを置き換えないかぎり、コンストラクタを事実上削除します。 パラメータのないデフォルト・コンストラクタには、その宣言のクラスと同じアクセス修飾子が与えられるため、既存のバイナリとの互換性を保持する場合は、すべての置換に同じかそれ以上のアクセス権が必要です。

メソッドまたはコンストラクタの型パラメータを追加または削除しても、バイナリ互換性には影響しません。

このような型パラメータがメソッドまたはコンストラクタの型で使用されている場合、前述の型の変更には通常の意味がある可能性があります。

メソッドまたはコンストラクタの型パラメータの名前を変更しても、既存のバイナリには影響しません。

メソッドまたはコンストラクタの型パラメータの最初の境界を変更すると、その型パラメータを独自の型で使用しているメンバーの消去(§4.6)が変更され、バイナリ互換性に影響する可能性があります。 具体的には、次のようになります。

他のバインドを変更しても、バイナリ互換性には影響しません。

メソッドまたはコンストラクタの仮パラメータの名前を変更しても、既存のバイナリには影響しません。

メソッドの名前、または仮パラメータの型をメソッドまたはコンストラクタに変更したり、パラメータを追加したり、メソッドまたはコンストラクタ宣言からパラメータを削除すると、新しいシグネチャを持つメソッドまたはコンストラクタで、古いシグネチャを持つメソッドまたはコンストラクタを削除し、新しいシグネチャを持つメソッドまたはコンストラクタを追加した場合(§13.4.12)。

メソッドの最後の仮パラメータの型をT[]からT型の可変引数パラメータ、つまりT... (§8.4.1)に変更しても、既存のバイナリには影響しません。

バイナリ互換性のために、署名に型変数(§4.4)またはパラメータ化された型(§4.5)が含まれるメソッドまたはコンストラクタmを追加または削除することは、署名がmの署名の消去(§4.6)である他の同等のメソッドの追加(それぞれ削除)と同等です。

メソッドの結果型を変更したり、結果型をvoidに置き換えたり、voidを結果型に置き換えたりすると、古いメソッドを削除し、新しい結果型または新しくvoid結果で新しいメソッドを追加するという効果が結合されます(§13.4.12を参照)。

バイナリ互換性のために、戻り型が型変数(§4.4)またはパラメータ化された型(§4.5)を含むメソッドまたはコンストラクタmを追加または削除することは、戻り型がmの戻り型(§4.6)の消去(§4.6)である他の同等のメソッドの追加(それぞれ削除)と同等です。

abstractと宣言されているメソッドをabstractと宣言しないように変更しても、既存のバイナリとの互換性は損なわれません。

abstractを宣言されていないメソッドをabstractとして変更すると、そのメソッドを以前に起動した既存のバイナリとの互換性が損なわれ、AbstractMethodErrorが発生します。

class Super { void out() { System.out.println("Out"); } }
class Test extends Super {
    public static void main(String[] args) {
        Test t = new Test();
        System.out.println("Way ");
        t.out();
    }
}

Way
Out

abstract class Super {
    abstract void out();
}

finalと宣言されているメソッドをfinalと宣言しないように変更しても、既存のバイナリとの互換性は損なわれません。

finalを宣言されていないインスタンス・メソッドをfinalとして変更すると、メソッドをオーバーライドする機能に依存する既存のバイナリとの互換性が損なわれる可能性があります。

class Super { void out() { System.out.println("out"); } }
class Test extends Super {
    public static void main(String[] args) {
        Test t = new Test();
        t.out();
    }
    void out() { super.out(); }
}

out

class Super { final void out() { System.out.println("!"); } }

finalを宣言されていないクラス(static)メソッドをfinalとして変更しても、既存のバイナリとの互換性は損なわれません。これは、メソッドをオーバーライドできなかったためです。

メソッドのnative修飾子を追加または削除しても、既存のバイナリとの互換性は損なわれません。

型の変更が、再コンパイルされていない既存のnativeメソッドに与える影響は、この仕様の範囲外であるため、実装の説明とともに指定する必要があります。 このような影響を制限する方法でnativeメソッドを実装することをお薦めしますが、必須ではありません。

privateが宣言されていないメソッドもstatic (つまり、クラス・メソッド)として宣言され、static (つまり、インスタンス・メソッド)が宣言されないように変更された場合、またはその逆の場合、既存のバイナリとの互換性が損なわれ、既存のバイナリでこれらのメソッドが使用されている場合、リンク時間エラー(つまり、IncompatibleClassChangeError)が発生する可能性があります。 このような変更は、広く配布されているコードではお薦めしません。

メソッドのsynchronized修飾子を追加または削除しても、既存のバイナリとの互換性は損なわれません。

メソッドまたはコンストラクタのthrows句を変更しても、既存のバイナリとの互換性が損なわれることはありません。これらの句はコンパイル時にのみチェックされます。

メソッドまたはコンストラクタの本体を変更しても、既存のバイナリとの互換性が損なわれることはありません。

メソッドのキーワードfinalは、メソッドを安全にインライン化できることを意味するものではなく、メソッドをオーバーライドできないことを意味します。 そのメソッドの新しいバージョンがリンク時に提供される可能性は依然としてあります。 また、元のプログラムの構造は、反射のために保存する必要があります。

したがって、Javaコンパイラはコンパイル時にインラインでメソッドを拡張できないことに注意してください。 一般に、実装では遅延(実行時)コードの生成と最適化を使用することをお薦めします。

既存のメソッドまたはコンストラクタをオーバーロードする新しいメソッドまたはコンストラクタを追加しても、既存のバイナリとの互換性が損なわれることはありません。 各呼出しに使用されるシグネチャは、これらの既存のバイナリがコンパイルされたときに決定されたため、新しく追加されたメソッドまたはコンストラクタは、そのシグネチャが適用可能であり、最初に選択されたシグネチャよりも限定的である場合でも使用されません。

新しいオーバーロードされたメソッドまたはコンストラクタを追加すると、クラスまたはインタフェースが次回コンパイルされるときにコンパイル時にエラーが発生することがあります。これは、最も具体的なメソッドまたはコンストラクタがないためです(§15.12.2.5)。このエラーは、実行時にオーバーロード解決が行われないため、プログラムの実行時に発生しません。

class Super {
    static void out(float f) {
        System.out.println("float");
    }
}
class Test {
    public static void main(String[] args) {
        Super.out(2);
    }
}

float

class Super {
    static void out(float f) { System.out.println("float"); }
    static void out(int i)   { System.out.println("int");   }
}

float

int

インスタンス・メソッドがサブクラスに追加され、スーパークラスのメソッドをオーバーライドした場合、サブクラス・メソッドは既存のバイナリのメソッド呼出しによって検出され、これらのバイナリは影響を受けません。

クラス・メソッドがクラスに追加された場合、メソッド呼出しの修飾クラスがサブクラスでないかぎり、このメソッドは見つかりません。

クラスの静的イニシャライザ(§8.7)を追加、削除または変更しても、既存のバイナリには影響しません。

enumクラス内でenum定数を追加したり、並べ替えても、既存のバイナリとの互換性が失われることはありません。

sealedクラス(§13.4.2.1)と同様に、enumクラスにenum定数を追加することはバイナリ互換の変更とみなされますが、コンパイル時に不明な新しいenum定数(§14.11.3、§15.28.2)がswitchで検出された場合、完全なswitch (§14.11.1)の実行が失敗する可能性があります。

enumクラスからenum定数を削除すると、enum定数に対応するpublicフィールドが削除されます(§8.9.3)。 結果は、§13.4.8に記載されています。 広く配布されるenumクラスについては、このような変更はお薦めしません。

他のあらゆる点において、enumクラスに関するバイナリ互換性のルールは標準クラスに関するものと同じです。

レコードクラス内のレコードコンポーネントを追加、削除、変更、または並べ替えると、再コンパイルされていない既存のバイナリとの互換性が損なわれる可能性があります。このような変更は、広く配布されているレコードクラスでは推奨されません。

より正確には、レコード・コンポーネントの追加、削除、変更または順序変更によって、コンポーネント・フィールドおよびアクセッサ・メソッドの対応する暗黙的な宣言が変更されるだけでなく、正規コンストラクタおよびその他のサポート・メソッドの署名および実装が変更される可能性があり、その結果は§13.4.8および§13.4.12で指定されます。

他のすべての点では、レコード・クラスのバイナリ互換性ルールは通常のクラスのルールと同じです。

publicを宣言されていないインタフェースをpublicとして変更しても、既存のバイナリとの互換性は損なわれません。

publicと宣言されているインタフェースがpublicと宣言されないように変更されると、既存のバイナリがリンクされていて、そのインタフェース・タイプにアクセスできなくなった場合、IllegalAccessErrorがスローされます。そのため、広く分散しているインタフェースでは、このような変更はお薦めしません。

自由に拡張可能なインタフェース(§9.1.1.4)がsealedとして宣言されるように変更された場合、このインタフェースの既存のサブクラスまたはサブインタフェースのバイナリがロードされ、このインタフェースの直接サブクラスまたはサブインタフェース(§9.1.4)が許可されていない場合、IncompatibleClassChangeErrorがスローされます。このような変更は、広く分散されているクラスにはお薦めしません。

sealedインタフェースの許可された直接サブクラスまたはサブインタフェースのセットにクラスまたはインタフェースを追加しても、既存のバイナリとの互換性は損なわれません。

sealedクラス(§13.4.2.1)と同様に、sealedインタフェースの許可された直接サブクラスまたはサブインタフェースを追加することは、バイナリ互換の変更とみなされる一方で、switchがコンパイル時に不明であった新しい許可された直接サブクラスまたはサブインタフェースのインスタンス(§14.11.3、§15.28.2)に遭遇した場合に、完全なswitch (§14.11.1)の実行が失敗することがあります。

sealedインタフェースの許可された直接サブクラスまたはサブインタフェースのセットからクラスまたはインタフェースが削除された場合、削除されたクラスまたはインタフェースの既存のバイナリがロードされると、IncompatibleClassChangeErrorがスローされます。

non-sealedとして宣言されたインタフェースをsealedに変更しても、既存のバイナリとの互換性は損なわれません。

non-sealedインタフェースIには、sealed直接スーパーインタフェースが必要です。 non-sealed修飾子を削除すると、sealedダイレクト・スーパーインタフェースを持つすべてのインタフェースがsealedまたはnon-sealedである必要があるため、Iの再コンパイルが妨げられます。

sealed直接スーパーインタフェースを持たないインタフェースからsealed修飾子を削除しても、既存のバイナリとの互換性は損なわれません。

シール済インタフェースIにsealedダイレクト・スーパーインタフェースが存在する場合、sealed修飾子を削除すると、sealedダイレクト・スーパーインタフェースを持つすべてのインタフェースがsealedまたはnon-sealedである必要があるため、Iの再コンパイルが妨げられます。

インタフェース階層を変更すると、§13.4.4で説明されているように、クラス階層の変更と同じ方法でエラーが発生します。 特に、クラスの以前のスーパーインタフェースがスーパーインタフェースでなくなった変更によって、既存のバイナリとの互換性が損なわれ、VerifyErrorが発生する可能性があります。

abstract、privateまたはstaticメソッドをインタフェースに追加しても、既存のバイナリとの互換性は損なわれません。

Cのスーパーインタフェースにフィールドを追加すると、Cのスーパークラスから継承されたフィールドが非表示になることがあります。 元の参照がインスタンス・フィールドに対するものであった場合、IncompatibleClassChangeErrorが生成されます。 元の参照が代入だった場合は、IllegalAccessErrorが結果になります。

インタフェースからメンバーを削除すると、既存のバイナリでリンク・エラーが発生する可能性があります。

interface I { void hello(); }
class Test implements I {
    public static void main(String[] args) {
        I anI = new Test();
        anI.hello();
    }
    public void hello() { System.out.println("hello"); }
}

hello

interface I {}

インタフェースの型パラメータに対する変更の影響は、クラスの型パラメータに類似した変更の影響と同じです。

インタフェースのフィールド宣言を変更する場合の考慮事項は、§13.4.8および§13.4.9で説明されているように、クラスのstatic finalフィールドの考慮事項と同じです。

インタフェースのメソッド宣言を変更する際の考慮事項には、§13.4.7、§13.4.14、§13.4.15、§13.4.19、§13.4.21、§13.4.22および§13.4.23で説明されているように、クラス内のメソッドを変更するための考慮事項が含まれます。

defaultメソッドを追加したり、メソッドをabstractからdefaultに変更しても、既存のバイナリとの互換性は損なわれませんが、既存のバイナリがそのメソッドを呼び出そうとすると、IncompatibleClassChangeErrorが発生する可能性があります。 このエラーは、メソッド呼出しの修飾インタフェースKが2つのインタフェース(IとJ)のサブインタフェースであり、IとJの両方が同じシグネチャと結果を持つdefaultメソッドを宣言し、IとJのいずれも他方のサブインタフェースではない場合に発生します。

つまり、デフォルト・メソッドを追加することは、コンパイル時または起動時にエラーが発生した場合でも、リンク時にエラーが発生しないため、バイナリ互換の変更です。 実際には、デフォルト・メソッドを導入して偶発的なクラッシュが発生するリスクは、final以外のクラスに新しいメソッドを追加することに関連するものと似ています。 衝突が発生した場合、クラスにメソッドを追加すると、LinkageErrorがトリガーされる可能性はほとんどありませんが、子のメソッドを誤ってオーバーライドすると、予期しないメソッド動作が発生する可能性があります。 どちらの変更もコンパイル時にエラーが発生する可能性があります。

interface Painter {
    default void draw() {
        System.out.println("Here's a picture...");
    }
}

interface Cowboy {}

public class CowboyArtist implements Cowboy, Painter {
    public static void main(String... args) {
        new CowboyArtist().draw();
   }
}

Here's a picture...

interface Cowboy {
    default void draw() {
        System.out.println("Bang!");
    }
}

注釈インタフェースは、他のインタフェースとまったく同様に動作します。 注釈インタフェースからの要素の追加または削除は、メソッドの追加または削除に類似しています。 注釈インタフェースを繰り返し可能にする(§9.6.3)など、注釈インタフェースに対するその他の変更を制御する重要な考慮事項がありますが、これらはJava Virtual Machineによるバイナリのリンクには影響しません。 かわりに、このような変更は、プログラム内の注釈の存在を明らかにするJava SEプラットフォームでのリフレクティブAPIの動作に影響します。 API仕様は、基礎となる注釈インタフェース(§1.4)に対して様々な変更が行われた場合の動作を記述します。

注釈を追加または削除しても、Javaプログラミング言語のプログラムのバイナリ表現の正しいリンクには影響しません。