Java 8インターフェイスメソッドで「最終」が許可されないのはなぜですか？

Java 8の最も便利な機能の1つは、defaultインターフェースの新しいメソッドです。それらが導入された理由は基本的に2つあります（他にもある場合があります）。

• 実際のデフォルト実装を提供します。例：Iterator.remove()
• JDK APIの進化を可能にする。例：Iterable.forEach()

APIデザイナーの観点から、インターフェイスメソッドで他の修飾子を使用できるようにしたいと思っていましたfinal。これは、便利なメソッドを追加するときに役立ち、クラスの実装における「偶発的な」オーバーライドを防ぎます。

interface Sender {

    // Convenience method to send an empty message
    default final void send() {
        send(null);
    }

    // Implementations should only implement this method
    void send(String message);
}

上記がSenderクラスの場合、すでに一般的な方法です。

abstract class Sender {

    // Convenience method to send an empty message
    final void send() {
        send(null);
    }

    // Implementations should only implement this method
    abstract void send(String message);
}

さて、defaultとfinal明らかにキーワードを矛盾しているが、デフォルトでは自分自身をキーワード厳格に求められているだろう、私は微妙な違いを反映するために、この矛盾が意図的であると仮定しているので、「身体を持つクラス・メソッド」（ちょうどメソッド）と「インターフェースを本文付きのメソッド」（デフォルトのメソッド）、つまり、まだ理解していない違い。

ある時点で、Brian Goetzを引用して、インターフェースメソッドstaticなどの修飾子のサポートfinalはまだ完全には検討されていませんでした。

もう1つの部分は、finalメソッド、privateメソッド、protectedメソッド、staticメソッドなど、インターフェイスでクラス構築ツールをどの程度サポートするかです。答えは、まだわかりません。

2011年後半のその時以来、明らかに、staticインターフェイスのメソッドのサポートが追加されました。明らかに、これはJDKライブラリ自体に、などの多くの価値を追加しましたComparator.comparing()。

質問：

Java 8インターフェイスに到達しなかった理由final（およびstatic final）は何ですか？

この質問は、ある程度、Java 8インターフェースメソッドで「同期」が許可されない理由とは何ですか。

デフォルトのメソッドについて理解する重要なことは、主な設計目標は「インターフェースを（普通の）特性に変える」ことではなく、インターフェースの進化であるということです。2つはある程度重複していますが、前者の邪魔にならない後者に対応しようとしましたが、これらの質問をこの観​​点から見ると最もよく理解できます。（クラスメソッドは、インターフェイスメソッドが複数継承できるという事実により、意図が何であれ、インターフェイスメソッドとは異なることに注意してください。）

デフォルトメソッドの基本的な考え方は次のとおりです。これは、デフォルト実装を備えたインターフェースメソッドであり、派生クラスはより具体的な実装を提供できます。また、デザインセンターはインターフェイスの進化であったため、ソース互換性およびバイナリ互換性のある方法で、デフォルトのメソッドを事後的にインターフェイスに追加できることが重要な設計目標でした。

「なぜ最終的なデフォルトメソッドではないのか」に対する単純すぎる答えは、本体が単にデフォルトの実装ではなく、唯一の実装になるということです。これは少し単純な答えですが、問題がすでに疑わしい方向に向かっているという手がかりを与えてくれます。

最終的なインターフェイスメソッドが疑わしいもう1つの理由は、実装者に不可能な問題を引き起こすことです。たとえば、次のように仮定します。

interface A { 
    default void foo() { ... }
}

interface B { 
}

class C implements A, B { 
}

ここでは、すべてが良好です。からC継承foo()しAます。ここで、デフォルトでメソッドBを持つように変更したfooとします。

interface B { 
    default void foo() { ... }
}

さて、リコンパイルCに行くと、コンパイラーはどの振る舞いを継承するのかわからないfoo()ので、それCをオーバーライドする必要があります（そしてA.super.foo()同じ振る舞いを保持したい場合は委任することを選択できます）。Bはデフォルトを設定finalしておりA、作者の管理下にありませんCか？現在Cは回復不能に壊れています。オーバーライドせずにコンパイルするfoo()ことはできませんがfoo()、がfinalである場合はオーバーライドできませんB。

これはほんの一例ですが、要点は、メソッドのファイナリティは実際には、単一の継承クラス（通常は状態と動作を結び付ける）の世界で、単に動作を提供して乗算できるインターフェイスよりも意味のあるツールであることです遺伝性の。「他のどのインターフェイスが最終的なインプリメンターに混在する可能性があるか」について推論するのはあまりにも難しく、インターフェイスメソッドをfinalにすることでこれらの問題が発生する可能性があります（そして、インターフェイスを作成した人ではなく、それを実装しようとする貧しいユーザー。）

それらを許可しない別の理由は、それらがあなたが彼らが意味すると思うことを意味しないということです。デフォルトの実装は、クラス（またはそのスーパークラス）がメソッドの宣言（コンクリートまたは抽象）を提供しない場合にのみ考慮されます。デフォルトのメソッドがfinalであるが、スーパークラスがすでにメソッドを実装している場合、デフォルトは無視されます。これは、デフォルトの作成者がfinalを宣言するときに期待していたものとはおそらく異なります。（この継承動作は、デフォルトメソッドのデザインセンターを反映したものです-インターフェイスの進化。デフォルトのメソッド（または既存のインターフェイスメソッドへのデフォルトの実装）を、既に実装されている既存のインターフェイスに、変更せずに追加できるはずです。インターフェースを実装する既存のクラスの動作

lambdaメーリングリストでは、それについてたくさんの議論があります。それらすべてについて多くの議論が含まれていると思われるものの1つは次のとおりです。さまざまなインターフェイスメソッドの可視性（最終的な防御側でした）。

この議論では、元の質問の作者であるタルデンがあなたの質問と非常によく似た質問をします。

すべてのインターフェースメンバーを公開するという決定は、実際に不幸な決定でした。内部設計でインターフェイスを使用すると、実装のプライベートな詳細が明らかになるのは大きな問題です。

言語に曖昧なまたは互換性を損なうニュアンスを追加せずに修正するのは難しいものです。その規模の互換性の破れと潜在的な微妙さは良心的ではないと思われるため、既存のコードを破らないソリューションが存在する必要があります。

「package」キーワードをアクセス指定子として再実行できる可能性があります。インターフェースに指定子がないことはパブリックアクセスを意味し、クラスに指定子がないことはパッケージアクセスを意味します。インターフェースでどの指定子が意味をなすかは不明確です-特に、開発者の知識の負担を最小限に抑えるために、アクセス指定子が存在する場合、クラスとインターフェースの両方で同じであることを確認する必要があります。

デフォルトのメソッドがない場合、インターフェースのメンバーの指定子は、少なくともインターフェース自体と同じくらいに見える必要があると推測しました（そのため、インターフェースは実際にはすべての表示可能なコンテキストで実装できます）。とても確かです。

これが範囲内での議論の可能性さえあるかどうかについて明確なコミュニケーションはありましたか？そうでない場合は、他の場所で開催する必要があります。

最終的にブライアンゲッツの答えは次のとおりです。

はい、これはすでに検討されています。

ただし、現実的な期待を設定しましょう。言語やVMの機能は、このような些細なものであっても、長いリードタイムを持っています。Java SE 8の新しい言語機能のアイデアを提案する時期はかなり過ぎました。

したがって、スコープの一部ではなかったため、実装されなかった可能性が高いです。検討するために時間内に提案されたことはありません。

この件に関する最終的な防御方法についての別の白熱した議論で、ブライアンは再び言った：

そして、あなたはまさにあなたが望んだものを得ました。これがまさにこの機能が追加するものです-動作の多重継承。もちろん、私たちは人々がそれらを特性として使用することを理解しています。そして私たちは、彼らが提供する継承のモデルがシンプルでクリーンであることを保証するために努力してきました。同時に、私たちはそれらを単純かつクリーンに機能するものの境界を超えて押し出さないように選択しました。これは、「ああ、あなたは十分に行きませんでした」という反応につながる場合があります。しかし、実際には、このスレッドのほとんどは、グラスが98％しか満たされていないことに不満を抱いているようです。私はその98％を取り、それを使います！

したがって、これは、それが単にそれらの範囲の一部または設計の一部ではなかったという私の理論を補強します。彼らがしたことは、APIの進化の問題に対処するのに十分な機能を提供することでした。

@EJPからのコメントで言及されている回答については、「THE」の回答を見つけて特定することは困難です。世界には、明確な回答を提供できる人がおよそ2人（+/- 2人）います。そして疑いの余地はありませんが、答えは「最終的なデフォルトメソッドをサポートすることは、内部の呼び出し解決メカニズムを再構築する努力に値するものではなかった」のようなものにすぎないかもしれません。もちろんこれは憶測ですが、少なくともOpenJDKメーリングリストの（2人のうちの1人による）この声明のような微妙な証拠によって裏付けられています。

「「デフォルトのデフォルト」メソッドが許可されたとしたら、内部のinvokespecialからユーザーに見えるinvokeinterfaceに書き換える必要があるかもしれません。」

そして、OpenJDKのMethod :: is_final_methodメソッドで現在実装されているように、メソッドがメソッドである場合、メソッドが（実際に）最終的なメソッドであるとは単純に見なされないというような些細な事実。default

さらに、本当に「信頼できる」情報は、過度のウェブ検索やコミットログの読み取りによってさえ、実際に見つけることは困難です。invokeinterface命令に対応するインターフェイスメソッド呼び出しとクラスメソッド呼び出しの解決中に、invokevirtual命令に対応する可能性のあるあいまいさに関連している可能性があると思いました：invokevirtual命令の場合、メソッドを継承する必要があるため、単純なvtableルックアップがある場合がありますスーパークラスから、またはクラスによって直接実装されます。それとは対照的に、invokeinterface呼び出しはそれぞれの呼び出しサイトを調べて、この呼び出しが実際に参照しているインターフェースを見つける必要があります（これについては、HotSpot WikiのInterfaceCallsページで詳しく説明しています）。しかしながら、final方法は、どちらかに挿入されませんvtableのすべてで、またはに既存のエントリを置き換えるのvtable（参照klassVtable.cppを。ライン333）、同様に、デフォルトの方法は、中に既存のエントリを置き換えるのvtable（参照klassVtable.cpp、ライン202） 。したがって、実際の理由（したがって、答え）は（かなり複雑な）メソッド呼び出し解決メカニズムの奥深くに隠されている必要がありますが、これらの参照は、実際の答えを導き出すことができる他の人にとってのみ、それにもかかわらず役立つと見なされる可能性がありますそれから。

finalコンビニエンスインターフェースメソッドで指定する必要はないと思いますが、役立つかもしれないとは思いますが、コストがメリットを上回っているようです。

どちらの方法でも、デフォルトのメソッドに適切なjavadocを記述して、メソッドが何であり、許可されていないかを正確に示すことになります。このようにして、保証はありませんが、インターフェースを実装するクラスは実装を変更することが「許可されていません」。

誰でもCollection、インターフェイスに忠実なを作成し、メソッドで絶対に直感に反することを行うことができます。大規模な単体テストを作成する以外に、それを防ぐ方法はありません。

defaultメソッドをinterface拡張するクラスが実装のinterface有無にかかわらずoverride、メソッド内にキーワードを追加します。しかし、実装クラスにオーバーライドさせたくないメソッドを追加したい場合はどうでしょうか？さて、2つのオプションを利用できました。

1. default finalメソッドを追加します。
2. staticメソッドを追加します。

現在、Javaは、メソッド名とシグネチャがまったく同じ、つまり重複しているメソッドがclass2つ以上実装されている場合、クラスにそのメソッドの実装を提供する必要があると述べています。メソッドの場合、実装を提供できず、行き詰まっています。そして、それがキーワードがインターフェースで使用されない理由です。interfacesdefaultdefault finalfinal