Talk:Clone (Java method)

Java Stub‑class Low‑importance

	This article is within the scope of WikiProject Java, a collaborative effort to improve the coverage of Java on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.JavaWikipedia:WikiProject JavaTemplate:WikiProject JavaJava
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
Low	This article has been rated as Low-importance on the project's importance scale.

Untitled

Please keep adverts for your book out of the article unless you're using it as a direct reference. 142.232.8.200 (talk) 04:19, 24 June 2008 (UTC)[reply]

Isn't it a bit funny to first delete a reference ("shameless advert") and then to set a "citation needed" tag? ;-)

I do not know the "crappy book", but any references reviewing the "clone or copy constructor" debate should be welcome. I have added a link to Java Practices, but truly there are other sources.--Gerd-HH (talk) 08:36, 27 August 2008 (UTC)[reply]

Other Languages and Frameworks

Clone() appears in other languages too, like the CLS languages (C#, VB.NET, IronPython, etc under System.IClonable). Don't they get a mention? W3bbo (talk) 19:56, 27 January 2009 (UTC)[reply]

clone is obsolete?

I am removing the obsolete statement, and the reference to some Java site (which has incorrect statements, e.g. about having to implement clone in deriving classes). Faustus (talk) 15:29, 24 February 2009 (UTC)[reply]

Clone is fast, Serializable is slow.

At the end of the article it mentions using Serializable should be almost as fast as clone. This is crazy. Serializable is very slow. See "java-built-in" in these benchmarks: http://wiki.github.com/eishay/jvm-serializers/ —Preceding unsigned comment added by N4te (talk • contribs) 03:22, 24 September 2010 (UTC)[reply]

Right, the sources I can find[1] also explicitly note that serialization is significantly slower. Also, the statement that cloning by serialization "uses only one object's worth of extra memory" is obviously wrong – imagine cloning an object that contains two or more references to immutable objects like java.lang.String: Serialization would (unneccessarily) duplicate them all, while cloning would not. I also removed that statement. --Leo141 (talk) 11:40, 16 November 2010 (UTC)[reply]

Unclear, or possibly wrong, information

The article claims "Every type reference that needs to call the clone function must have a clone() method in its own class or a publicly accessible clone() method in its parent classes"

According to this, if I have an object of type A, and from this I happen to want to clone a different object of type B, then A must have a clone() method, which is not true at all. Can someone rewrite this to say whatever it was meant to say? Presumably, that every type reference that needs to _be cloned_ must have a clone() method ... &c. —Preceding unsigned comment added by 212.44.19.206 (talk) 15:29, 25 February 2011 (UTC)[reply]

Why no covariant clone implementations in Java 5+

Since Java5 covariant return types are possible, but still builtin classes like ArrayList#clone returns Object, not ArrayList. Is this due to compatibility? Older application sourcecode overriding clone with returning Object would no longer compile.

Did I miss something? If not, this should be fixed ASAP. — Preceding unsigned comment added by 193.147.15.66 (talk) 11:34, 19 December 2012 (UTC)[reply]

No Mention of Relation to Prototype Design Pattern?

Since clone() is an implementation of the Prototype design pattern, shouldn't there be at least some mention of the connection between the theory underlying the clone() method and the practice as it exists in Java with clone()? — Preceding unsigned comment added by 209.82.65.226 (talk) 17:36, 21 February 2013 (UTC)[reply]