clone() wegen leerem Cloneable quasi nutzlos?

[xehpuk]

Moin, Leute!

Kann es sein, dass dem Java-Team ein großer Fehler beim Implementieren des Klonmechanismus unterlaufen ist? Dass clone() in Object steht und Cloneable einfach nur leer ist, wirkt nicht nur auf den ersten Blick ziemlich dämlich, sondern auch noch auf den zweiten Blick.

Gibt es dafür eine logische Erklärung? Bei meiner bisherigen Recherche habe ich nur gelesen, dass da durch Zeitknappheit einfach nur ein Fehler gemacht wurde.

Nun ist es ja unter anderem so, dass man z. B. bei heterogenen Collections, die nur Cloneables beinhalten, Reflection benutzen muss, um überhaupt clone() auf die einzelnen Elemente aufrufen zu können.

Wenn es für diese Designentscheidung keine Erklärung gibt, gibt es dann wenigstens Aussicht auf eine Änderung in späteren JDKs?

 

[maki]

Joshua Bloch hat in seinem Buch "Effective Java" mal darauf hingewiesen das clone() in Java an sich eine Missgeburt ist und man es meiden sollte falls möglich, details weiss ich keine mehr dazu, da ich es nicht benutze.

So grundlegende Änderungen würde nicht nicht erwarten, speziell wenn es bedeuten würde dass alter Code sich anders verhält.

 

[slawaweis]

Kann es sein, dass dem Java-Team ein großer Fehler beim Implementieren des Klonmechanismus unterlaufen ist? Dass clone() in Object steht und Cloneable einfach nur leer ist, wirkt nicht nur auf den ersten Blick ziemlich dämlich, sondern auch noch auf den zweiten Blick.

Gibt es dafür eine logische Erklärung? Bei meiner bisherigen Recherche habe ich nur gelesen, dass da durch Zeitknappheit einfach nur ein Fehler gemacht wurde.

die ursprüngliche Idee (für Kaffeemaschinen und Toaster) war mit Cloneable ein Objekt zu markieren, damit die JVM weis, dass davon eine 1:1 binäre Kopie gemacht werden darf. Object.clone() müsste nur dann überschrieben werden, wenn man das Klonen/Kopieren zusätzlich kontrollieren wollte. Nur ist Klonen bei Objektnetzen alles andere als trivial, so dass dieser Ansatz den Anforderungen nicht genügte.

Wenn es für diese Designentscheidung keine Erklärung gibt, gibt es dann wenigstens Aussicht auf eine Änderung in späteren JDKs?

eher nicht. Diese Sache ist, wie das stop() in Thread, kaum pauschal zu definieren. Verschiedene Ansätze brauchen verschiedene Lösungen. Ich bevorzuge z.B. CloneFactories, wo das Klonen/Kopieren von einer externen Logik übernommen wird.

Slawa

 

[Empire Phoenix]

Bei primitiven Objecten ist clone() durchaus nützlich -> alles was keine Referenzen enthält kann man so schnell und effizient clonen. Allerdings ist es eindeutig ein DesignFehler das clone() in object drinnen ist. Da man es überschreiben kann kann man es aber zumindest an eigene Bedürfnisse problemlos anpassen.

Ich bevorzuge btw clone() selber zu implementieren für alle Objecte bei denen ich diese funktionalität brauche.

 

[homer65]

Es gab da mal hier im Forum einen Beitrag zum Thema. Stichwort war glaube ich "Deep Copy" oder so ähnlich.
Jedenfalls wurde ein Object in ein ByteArray zwischenkopiert und dann von da aus in ein anderes weiterkopiert.
War eine verhältnissmäßig einfache Art und Weise eine Kopie von einem Objekt zu bekommen.
Edit:
Habs gefunden:
http://www.java-forum.org/java-basics-anfaenger-themen/30995-deep-copy-objekten.html

 

[maki]

@homer65

Clonen per Serialisierung ist nicht die schnellste Art, aber u.U. die einfachste, wenn man wirklich clone() nutzen will.

 

[Wildcard]

Besser ist oft ein Copy Konstruktor, oder ein externer Mechanismus. Ein Beispiel dafür sind von EMF erzeugte Klassen die dank der erweiterten EMF Reflection einheitlich geklont werden können.