Cloneableが非推奨にならないのはなぜですか？

CloneableJavaのインターフェースが壊れていることは一般的に理解されています。これには多くの理由がありますが、これについては触れません。他の人はすでにそれをしました。また、Javaアーキテクト自身の立場でもあります。

したがって、私の質問は次のとおりです。なぜまだ非推奨になっていないのですか？コアJavaチームが破損していると判断した場合は、廃止も検討しているはずです。そうすることに対する彼らの理由は何ですか（Java 8ではまだ非推奨ではありません）？

にメソッドを追加することに関して、1997年にJava Bug Databaseに提出されたバグがあるため、もはや役に立たなくなります。それは「修正しない」という決議で閉鎖され、正当化は次のとおりでした。clone()Cloneable

SunのTechnical Review Committee（TRC）はこの問題を詳細に検討し、現在のCloneableインターフェースのドキュメントを改善する以外のアクションをとらないよう推奨しました。推奨事項の全文は次のとおりです。

既存のJavaオブジェクトの複製APIには問題があります。java.lang.Objectには保護された「clone」メソッドがあり、インターフェースjava.lang.Cloneableがあります。意図は、クラスが他の人に複製を許可したい場合は、Cloneableインターフェースをサポートし、デフォルトの保護された複製メソッドをpublic複製メソッドでオーバーライドする必要があるということです。あいにく、都合の悪いことに時間の経過とともに失われてしまう理由により、Cloneableインターフェースはcloneメソッドを定義していません。

この組み合わせにより、かなりの混乱が生じます。一部のクラスはCloneableをサポートしていると主張していますが、誤ってcloneメソッドのサポートを忘れています。開発者は、Cloneableがどのように機能し、どのように機能するのかについて混乱しています。

残念ながら、「clone」メソッドをCloneableに追加すると、互換性のない変更になります。バイナリ互換性は失われませんが、ソース互換性は失われます。事例証拠は、実際にはクラスがCloneableインターフェースをサポートしているが、パブリッククローンメソッドを提供できないケースが多数あることを示唆しています。議論の後、互換性への影響があるため、TRCは満場一致で既存のCloneableインターフェースを変更しないことを推奨しました。

別の提案は、Cloneableの本来の意図された目的を反映するために、新しいインターフェースjava.lang.PubliclyCloneableを追加することでした。5から2の過半数で、TRCはこれを推奨しませんでした。主な懸念は、これにより、すでに混乱している画像にさらに混乱（スペルの混乱を含む！）が追加されることでした。

TRCは満場一致で、既存のCloneableインターフェイスに追加のドキュメントを追加して、それがどのように使用されるかをより適切に説明し、実装者向けの「ベストプラクティス」を説明することを推奨しました。

したがって、これは直接非推奨ではありませんが、Cloneableを「非推奨」にしない理由は、Technical Review Comiteeが、既存のドキュメントを修正するだけでこのインターフェースを十分に活用できると判断したためです。そして彼らはそうしました。Java 1.4までCloneableは、次のように文書化されていました。

クラスはCloneableインターフェースを実装して、Object.clone（）メソッドに、そのクラスのインスタンスのフィールドごとのコピーを作成することが正当であることを示します。

Cloneableインターフェースを実装しないインスタンスのクローンを作成しようとすると、例外CloneNotSupportedExceptionがスローされます。

インターフェイスCloneableはメソッドを宣言しません。

Java 1.4（2002年2月にリリースされた）から最新版（Java 8）までは、次のようになります。

クラスはCloneableインターフェースを実装して、Object.clone（）メソッドに、そのクラスのインスタンスのフィールドごとのコピーを作成することが正当であることを示します。Cloneableインターフェースを実装していないインスタンスでObjectのcloneメソッドを呼び出すと、例外CloneNotSupportedExceptionがスローされます。

慣例により、このインターフェイスを実装するクラスは、Object.clone（保護されている）をパブリックメソッドでオーバーライドする必要があります。このメソッドのオーバーライドの詳細については、Object.clone（）を参照してください。

このインターフェースにはcloneメソッドが含まれていないことに注意してください。したがって、このインターフェイスを実装しているという事実だけでは、オブジェクトのクローンを作成することはできません。cloneメソッドがリフレクトで呼び出されても、成功する保証はありません。

「なぜCloneable廃止されないのですか？」に対する短い回答 （実際、がなぜX非推奨にならないのかX）は、それらを非推奨にすることにあまり注意が払われていないことです。

最近廃止されたもののほとんどは、それらを削除する特定の計画があるため、廃止されました。例えば、addPropertyChangeListener及びremovePropertyChangeListener方法のLogManagerをされたのJava SE 8で非推奨のJava SE 9でそれらを除去する目的で（その理由は、彼らが不必要にモジュールの依存関係を複雑にしていることである。）確かに、これらのAPIは、既にされている初期のJDK 9から削除開発ビルド。（同様のプロパティ変更リスナー呼び出しもから削除されていることに注意してPack200ください。JDK-8029806を参照してください。）

そのような同様の計画がのために存在しないCloneableとObject.clone()。

より長い回答には、これらのAPIに起こりそうなこと、プラットフォームが非推奨になった場合にプラットフォームに発生するコストやメリット、APIが非推奨になった場合に開発者に伝えられることなど、さらなる質問についての議論が含まれます。私は最近のJavaOneの講演であるDebt and Deprecationでこのトピックを調査しました。（そのリンクでスライドが利用可能です。ビデオはこちらです。）JDK自体は、非推奨の使用法について一貫性があまりないことがわかりました。たとえば、次のようないくつかの異なる意味で使用されています。

• これは危険であり、あなたがそれを使用することのリスクを認識する必要があります（例：Thread.stop()、Thread.resume()、およびThread.suspend()）。

• これは将来のリリースで削除される予定です

• これは時代遅れであり、別のものを使用することをお勧めします（例：のメソッドの多くjava.util.Date）

これらはすべて別個の意味であり、それらの異なるサブセットは、非推奨のさまざまなものに適用されます。そして、それらのサブセットの一部は、非推奨ではないものに適用されます（ただし、非推奨にする必要があるかもしれません）。

CloneableそしてObject.clone()、彼らは設計上の欠陥を持っているし、正しく使用することは困難であるという意味で「壊れた」されています。ただし、clone()それでも配列をコピーするための最良の方法であり、複製には、慎重に実装されたクラスのインスタンスのコピーを作成するためのいくつかの限定された有用性があります。クローンの削除は互換性のない変更であり、多くのことを壊します。クローン操作は別の方法で再実装することもできますが、おそらくそれよりも遅くなりObject.clone()ます。

ただし、ほとんどの場合、コピーよりもコピーコンストラクタの方が適しています。そのCloneableため、「廃止された」または「置き換えられた」などのマークを付けるのが適切な場合があります。これは、おそらく他の場所を調べたいと開発者に伝えますが、将来のリリースで複製メカニズムが削除される可能性があることを示すものではありません。残念ながら、そのようなマーカーは存在しません。

現状では、「非推奨」は最終的には削除されることを意味しているようです-廃止された機能のほとんどが削除されたという事実にもかかわらず-したがって、クローン作成メカニズムの非推奨は保証されていないようです。おそらく将来的には、代わりのメカニズムを使用するように開発者に指示する代替のマーキングを適用することができます。

更新

バグレポートにいくつかの履歴を追加しました。初期のJVM実装者であり、JVM仕様の共著者であるフランクイェリンは、他の回答で引用されているTRC勧告の「失われた時間の中で」のコメントに応えて、いくつかのコメントをしました。ここでは関連する部分を引用しました。完全なメッセージはバグレポートにあります。

Serializableにはないのと同じ理由で、Cloneableにはメソッドがありません。Cloneableは、クラスがサポートするメソッドについて具体的に何も言わずに、クラスのプロパティを示します。

リフレクションの前に、オブジェクトの浅いコピーを作成するためのネイティブメソッドが必要でした。したがって、Object.clone（）が生まれました。また、多くのクラスがこのメソッドをオーバーライドすることを望み、すべてのクラスが複製されることを望まないことも明らかでした。したがって、Cloneableはプログラマーの意図を示すために生まれました。

つまり、要するに。Cloneableの目的は、パブリックclone（）メソッドがあることを示すことではありませんでした。Object.clone（）を使用してクローンを作成する意思があることを示すためであり、clone（）を公開するかどうかを決定するのは実装次第でした。

なぜまだ非推奨になっていないのですか？

JCPがそうするのに適していないので、そうすることは決してないかもしれないからです。それらを尋ねます。間違った場所で質問しています。

これをJava APIで維持する背後にある理由は何ですか

下位互換性の要件があるため、Java APIから何も削除されることはありません。最後に起こったのは、1996/7における1.0と1.1の間のAWTイベントモデルの変更でした。