Javaの以前のバージョンでは、 Marker Interfaces がクラスに関するメタデータを宣言する唯一の方法でした。たとえば、Serializable Marker Interfaceを使用すると、クラスの作成者は、クラスがシリアル化および逆シリアル化されたときに正しく動作するようになります。
現代のJavaでは、マーカーインターフェイスには場所がありません。これらは、非常に柔軟なメタデータ機能を可能にする Annotations で完全に置き換えることができます。クラスに関する情報があり、その情報が決して変わらない場合、注釈はそれを表す非常に便利な方法です。
Joshua Bloch：Effective Java 2nd Edition、p 179
項目37：マーカーインターフェイスを使用して型を定義する
...マーカーアノテーション（項目35）がマーカーインターフェイスを廃止すると言っているのを聞くかもしれません。この主張は誤りです。マーカーインターフェイスには、マーカーアノテーションよりも2つの利点があります。何よりもまず、マーカーインターフェイスは、マークされたクラスのインスタンスによって実装されるタイプを定義します。マーカー注釈はサポートしません。このタイプの存在により、マーカー注釈を使用した場合、実行時までキャッチできないエラーをコンパイル時にキャッチできます。
個人的には、この主題に関するジョシュアの優れた知識に屈することになると思います。
このようなマーカーインターフェイスは、オブジェクトがマーカーインターフェイスを実装しているかどうかに応じて他のコードが決定を下す場合に役立ちます。
Serializableの場合、オブジェクトのフィールドをシリアル化するためにリフレクションが使用されます。
現在は、サブクラスに伝播しないため、注釈が優先されます。
Marker interface pattern を参照してください。
これは、クラス（および結果的に一時的でないすべてのフィールド）がシリアル化の候補であることを示しています。そして、シリアライゼーションに依存するフレームワークを構築している場合、もちろん次のようにメソッドを書くことができます。
public void registerObject(Serializable obj);
受け入れる準備ができているクラスを制限します。
シリアル化されたオブジェクトはシステム間で互換性を保持する必要があるため、シリアル化は明示的な設計決定であり、そのような候補を識別するにはマーカーインターフェイスの使用が必要です。
セキュリティ面もあります。すべてをシリアル化可能にしたくない-そうしないと、シリアル化によって誤ってパスワードやその他の機密データを公開する可能性があります。
これらはmarkerインターフェイスと呼ばれます。そしてその名前が示すように、それらはマークある種の操作に何らかのオブジェクトが利用可能であることを意味します。
Serializableは、オブジェクトがJavaシリアライゼーションなど）に適格であることを意味します。
それらの機能は非常に似ているので、それらを注釈で置き換えるべきではないかどうかが議論されています。
インターフェイスを実装する場合、instanceofはtrueになります。インターフェースに実装するものがない場合は、これを使用して、Java 1.5以上のアノテーションのようにメタデータでクラスをマークできます。実装者に特別なことを強制する必要はありません。
空のインターフェイスは、フィールドの検査/変更およびメソッドのディスパッチに基づいたプログラムの「標準」実行に影響を与えないというのは理にかなっています。
ただし、マーカーインターフェイスはリフレクションと組み合わせて使用すると便利です。ライブラリ/メソッドはオブジェクトを（リフレクションを介して）検査し、そのクラスがマーカーインターフェイスを実装している場合は動作が異なります。 Java5の時点では、マーカーインターフェイスの必要性はほとんどありません。同じ「マーキング」機能はJavaアノテーション-これも（再び）リフレクションベースのコードによって達成されます）。