Talk:Clone (Java method)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Untitled[edit]

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[edit]

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?[edit]

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.[edit]

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 (talkcontribs) 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[edit]

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+[edit]

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?[edit]

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]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Clone (Java method). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:29, 9 August 2017 (UTC)[reply]