Warum ist Cloneable nicht veraltet?

Es ist allgemein bekannt, dass die CloneableSchnittstelle in Java defekt ist. Es gibt viele Gründe dafür, die ich nicht erwähnen werde; andere haben es schon getan. Es ist auch die Position der Java-Architekten selbst.

Meine Frage ist daher: Warum wurde noch nicht veraltet? Wenn das Java-Kernteam entschieden hat, dass es defekt ist, muss es auch die Ablehnung in Betracht gezogen haben. Was sind ihre Gründe dagegen (in Java 8 ist es immer noch nicht veraltet )?

Es gibt einen Fehler, der 1997 bei der Java Bug Database über das Hinzufügen von clone()Methoden zu gemeldet wurde Cloneable, sodass er nicht mehr unbrauchbar wäre. Es wurde mit der Entschließung "wird nicht behoben" geschlossen und die Begründung lautete wie folgt:

Das Technical Review Committee (TRC) von Sun hat dieses Problem ausführlich geprüft und empfohlen, keine anderen Maßnahmen als die Verbesserung der Dokumentation der aktuellen klonbaren Schnittstelle zu ergreifen . Hier ist der vollständige Text der Empfehlung:

Die vorhandenen APIs zum Klonen von Java-Objekten sind problematisch. Es gibt eine geschützte "Klon" -Methode für java.lang.Object und eine Schnittstelle für java.lang.Cloneable. Wenn eine Klasse anderen Personen das Klonen erlauben soll, sollte sie die klonbare Schnittstelle unterstützen und die standardmäßige geschützte Klonmethode mit einer öffentlichen Klonmethode überschreiben. Leider definiert die klonbare Schnittstelle aus Gründen, die im Nebel der Zeit verloren gehen, keine Klonmethode.

Diese Kombination führt zu ziemlich viel Verwirrung. Einige Klassen behaupten, Cloneable zu unterstützen, vergessen jedoch versehentlich, die Clone-Methode zu unterstützen. Entwickler sind verwirrt darüber, wie Cloneable funktionieren soll und was Clone tun soll.

Leider wäre das Hinzufügen einer "Klon" -Methode zu Cloneable eine inkompatible Änderung. Die Binärkompatibilität wird dadurch nicht beeinträchtigt, die Quellkompatibilität wird jedoch beeinträchtigt. Anekdoten weisen darauf hin, dass es in der Praxis eine Reihe von Fällen gibt, in denen Klassen die klonbare Schnittstelle unterstützen, jedoch keine öffentliche Klonmethode bereitstellen. Nach der Diskussion empfahl TRC einstimmig, die vorhandene klonbare Schnittstelle wegen der Auswirkungen auf die Kompatibilität NICHT zu ändern.

Ein alternativer Vorschlag bestand darin, eine neue Schnittstelle java.lang.PubliclyCloneable hinzuzufügen, um den ursprünglich beabsichtigten Zweck von Cloneable widerzuspiegeln. Mit einer Mehrheit von 5 zu 2 empfahl TRC dagegen. Das Hauptanliegen war, dass dies einem bereits verwirrten Bild noch mehr Verwirrung (einschließlich Rechtschreibverwirrung!) Veranlassen würde.

TRC empfahl einstimmig, der vorhandenen klonbaren Schnittstelle zusätzliche Dokumentation hinzuzufügen, um besser zu beschreiben, wie sie verwendet werden soll, und um "Best Practices" für Implementierer zu beschreiben.

Obwohl dies nicht direkt veraltet ist , liegt der Grund dafür, dass Cloneable nicht "veraltet" ist, darin, dass das Technical Review Comitee entschieden hat, dass die Änderung der vorhandenen Dokumentation ausreicht , um diese Schnittstelle nützlich zu machen. Und so taten sie es. Bis Java 1.4 Cloneablewurde wie folgt dokumentiert:

Eine Klasse implementiert die klonbare Schnittstelle, um der Object.clone () -Methode anzuzeigen, dass es für diese Methode zulässig ist, eine Feld-für-Feld-Kopie von Instanzen dieser Klasse zu erstellen.

Versuche, Instanzen zu klonen, die die klonbare Schnittstelle nicht implementieren, führen dazu, dass die Ausnahme CloneNotSupportedException ausgelöst wird.

Die Schnittstelle Cloneable deklariert keine Methoden.

Seit Java 1.4 (das im Februar 2002 veröffentlicht wurde) bis zur aktuellen Ausgabe (Java 8) sieht es folgendermaßen aus:

Eine Klasse implementiert die klonbare Schnittstelle, um der Object.clone () -Methode anzuzeigen, dass es für diese Methode zulässig ist, eine Feld-für-Feld-Kopie von Instanzen dieser Klasse zu erstellen. Das Aufrufen der Klonmethode von Object für eine Instanz, die die klonbare Schnittstelle nicht implementiert, führt dazu, dass die Ausnahme CloneNotSupportedException ausgelöst wird.

Gemäß der Konvention sollten Klassen, die diese Schnittstelle implementieren, Object.clone (das geschützt ist) mit einer öffentlichen Methode überschreiben. Weitere Informationen zum Überschreiben dieser Methode finden Sie unter Object.clone ().

Beachten Sie, dass diese Schnittstelle die Klonmethode nicht enthält. Daher ist es nicht möglich, ein Objekt nur aufgrund der Tatsache zu klonen, dass es diese Schnittstelle implementiert. Selbst wenn die Klonmethode reflektierend aufgerufen wird, gibt es keine Garantie dafür, dass sie erfolgreich ist.

Die kurze Antwort auf "Warum ist nicht Cloneableveraltet?" (oder in der Tat, warum wird es nicht Xveraltet X) ist, dass nicht viel darauf geachtet wurde, sie zu verwerfen.

Die meisten Dinge, die kürzlich veraltet waren, wurden veraltet, weil es einen bestimmten Plan gibt, sie zu entfernen. Zum Beispiel können die addPropertyChangeListenerund removePropertyChangeListenerMethoden der LogManager wurden als veraltet in Java SE 8 (ist der Grund , dass sie Modul Interdependenzen unnötig kompliziert.) Mit der Absicht, sie in Java SE 9. Entfernen der Tat haben diese APIs bereits von Anfang JDK 9 entfernt Entwicklung baut. (Beachten Sie, dass ähnliche Listener-Aufrufe zur Änderung von Eigenschaften auch aus entfernt wurden Pack200; siehe JDK-8029806 .)

Für Cloneableund gibt es keinen ähnlichen Plan Object.clone().

Eine längere Antwort würde die Erörterung weiterer Fragen beinhalten, z. B. was mit diesen APIs zu erwarten ist, welche Kosten oder Vorteile der Plattform entstehen würden, wenn sie veraltet wären, und was den Entwicklern mitgeteilt wird, wenn eine API veraltet ist. Ich habe dieses Thema in meinem letzten JavaOne-Vortrag " Schulden und Verfall" untersucht . (Folien unter diesem Link verfügbar; Video hier .) Es stellt sich heraus, dass das JDK selbst in seiner Verwendung von Verfall nicht sehr konsistent war. Es wurde verwendet, um verschiedene Dinge zu bedeuten, einschließlich zum Beispiel:

• Dies ist gefährlich , und Sie sollten die Risiken der Verwendung es bewusst sein (Beispiel: Thread.stop(), Thread.resume(), und Thread.suspend()).

• Dies wird in einer zukünftigen Version entfernt

• Dies ist veraltet und es ist eine gute Idee, etwas anderes zu verwenden (Beispiel: viele der Methoden in java.util.Date)

All dies sind unterschiedliche Bedeutungen, und verschiedene Untergruppen davon gelten für verschiedene Dinge, die veraltet sind. Und einige Untergruppen davon gelten für Dinge, die nicht veraltet sind (die aber möglicherweise veraltet sein sollten).

Cloneableund Object.clone()sind "kaputt" in dem Sinne, dass sie Designfehler aufweisen und schwer richtig zu verwenden sind. Dies clone()ist jedoch immer noch der beste Weg, um Arrays zu kopieren, und das Klonen ist nur begrenzt nützlich, um Kopien von Instanzen von Klassen zu erstellen, die sorgfältig implementiert wurden. Das Entfernen des Klonens wäre eine inkompatible Änderung, die viele Dinge kaputt machen würde. Ein Klonvorgang könnte auf andere Weise erneut implementiert werden, wäre aber wahrscheinlich langsamer als Object.clone().

In den meisten Fällen ist jedoch ein Kopierkonstruktor dem Klonen vorzuziehen. Vielleicht Cloneablewäre es angebracht , sie als "veraltet" oder "ersetzt" oder ähnliches zu markieren . Dies würde Entwicklern mitteilen, dass sie wahrscheinlich woanders suchen möchten, aber es würde nicht signalisieren, dass der Klonmechanismus in einer zukünftigen Version möglicherweise entfernt wird. Leider existiert kein solcher Marker.

Aus heutiger Sicht scheint "Abwertung" eine eventuelle Entfernung zu bedeuten - trotz der Tatsache, dass eine verschwindend kleine Anzahl veralteter Features jemals entfernt wurde - und daher scheint eine Abwertung für den Klonmechanismus nicht gerechtfertigt zu sein. Vielleicht kann in Zukunft eine alternative Kennzeichnung angewendet werden, die Entwickler anweist, stattdessen alternative Mechanismen zu verwenden.

AKTUALISIEREN

Ich habe dem Fehlerbericht einen zusätzlichen Verlauf hinzugefügt . Frank Yellin, ein früher JVM-Implementierer und Mitautor der JVM-Spezifikation, gab einige Kommentare als Antwort auf den Kommentar "Verloren im Nebel der Zeit" in der in der anderen Antwort zitierten TRC-Empfehlung ab . Ich habe die relevanten Teile hier zitiert; Die vollständige Meldung befindet sich im Fehlerbericht.

Cloneable hat aus dem gleichen Grund keine Methoden wie Serializable. Klonbar gibt eine Eigenschaft der Klasse an, anstatt speziell etwas über die von der Klasse unterstützten Methoden zu sagen.

Vor der Reflexion benötigten wir eine native Methode, um eine flache Kopie eines Objekts zu erstellen. Daher wurde Object.clone () geboren. Es war auch klar, dass viele Klassen diese Methode überschreiben möchten und dass nicht jede Klasse geklont werden möchte. Daher wurde Cloneable geboren, um die Absicht des Programmierers anzuzeigen.

Kurz gesagt. Der Zweck von Cloneable bestand nicht darin, anzuzeigen, dass Sie eine öffentliche clone () -Methode hatten. Dies sollte darauf hinweisen, dass Sie bereit waren, mit Object.clone () geklont zu werden, und es lag an der Implementierung, zu entscheiden, ob clone () veröffentlicht werden soll oder nicht.

warum ist es noch nicht veraltet?

Weil die JCP dies nicht für richtig gehalten hat und dies möglicherweise niemals tun wird. Frag sie. Du fragst am falschen Ort.

Was sind die Gründe dafür, dass dieses Ding in der Java-API bleibt?

Aufgrund der Abwärtskompatibilitätsanforderungen wird niemand jemals etwas aus der Java-API entfernen. Das letzte Mal geschah 1996/7 die Änderung des AWT-Ereignismodells zwischen 1,0 und 1,1.