@ FunctionalInterfaceはJVMのランタイム動作にどのように影響しますか？

Question

私の最初の質問はthis oneの正確な複製でした。つまり、このインタフェースに実行時保存ポリシーが設定されているのはなぜですか。

しかし、受け入れ答えは、2つの理由のために、すべてで私を満たしていない：

• このインタフェースは@Documentedであるという事実は、（（私は信じている）、それとは何の関係もありません@Documentedは、実行時の保持力を持っている理由が、ポリシーは私にとっても謎です）。 （答えは言及としてComparable、だけでなく、Runnableなど）
• は多くが「だろう」にもかかわらず、機能のインターフェイスは、前のJava 8にJavaで存在し、これは、あなたができるインスタンスの「代替」（として使用されてからそれらを防ぐことはできません。あなたがしていることがPathなどのフィルタであれば、Predicateの代わりにDirectoryStream.Filterを使用してください）。

しかし、それでもこの保持はあります。つまり、何とかJVMの動作に影響を与えなければならないということです。どうやって？

Answer 1

@FunctionalInterface注釈の保存について説明しているcore-libs-devメーリングリストにthreadが見つかりました。ここで言及されている主なポイントは、サードパーティのツールがコード分析/検証にこの情報を使用し、Java以外のJVM言語がラムダを関数インタフェースに正しくマップできるようにすることです。いくつか抜粋：

ジョーダーシー（@FunctionalInterfaceの元コミッター）：

我々が意図的にこの注釈を作ったが にランタイム保持を持って、それはまた、実行時にさまざまなツールを照会することができるようにする、など

ブライアン・ゲッツ

以外のにはJavaよりも利点があります。これは、インタフェースがSAM変換機構に渡すのに適しているかどうかを判断する手段として使用できます。ラムダ変換のJDKサポートは他の言語でも利用できます。

これはJVM自体では使用されていないようだが、サードパーティ製ツールの追加の可能性がある。アノテーションをランタイムに見えるようにすることは大きなコストではないので、強い理由がないようです。これは行いません。

Answer 2

保持ポリシーのランタイムと注釈のための唯一の要件は、

注釈はコンパイラによってクラスファイルに記録され、実行時にVMによって保持されるので、彼らは、リフレクション読み取ることができます。 （https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/RetentionPolicy.html#RUNTIME）

クラスローダは、これらのannoationsをロードする必要がありますし、VMが（サードパーティのライブラリによって、例えば）反射のアクセスのためにメモリ内にこれらのアノテーションを保持しなければならないので、今これは、実行時の動作に何らかの影響を持っています。

ただし、このようなアノテーションにVMが動作する必要はありません。