tag:blogger.com,1999:blog-8866592669665585195.post5348683779300971646..comments2024-02-10T14:08:31.576+02:00Comments on Red and Sensual Java: No clone for you!Yardenahttp://www.blogger.com/profile/15649241856669571499noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-8866592669665585195.post-2815608212564023062008-12-07T21:31:00.000+02:002008-12-07T21:31:00.000+02:00Thanks for great comments guys. I remembered readi...Thanks for great comments guys. <BR/><BR/>I remembered reading about clone, but for some reason I thought it was the JLS, while it was in fact Effective Java - thanks for the reference, Itay. <BR/><BR/>Paul - I agree that marker interface makes no sense. When I originally planned the post, I wanted to make a case against the whole marker interface practice. Serializable is pretty awful too.Yardenahttps://www.blogger.com/profile/15649241856669571499noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-38166057368302594962008-12-07T19:55:00.000+02:002008-12-07T19:55:00.000+02:00I think I just guessed why protected. To force you...I think I just guessed why protected. To force you to implement your own clone. The marker interface Cloneable then seems questionable. Why not use a template method isConeable() which returns false unless you override?<BR/><BR/>More questions you ask the more confusing it gets. It reminds me of the kind of code you write when your backs against the wall and you've got a deadline to meet.<BR/><BR/>Java was rushed out in a bit of a panic. I wonder if they are doing the same again with JavaFX Script? Hmmm...Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-23539241240087016402008-12-07T19:52:00.000+02:002008-12-07T19:52:00.000+02:00Just so that we all get a little bit more confused...Just so that we all get a little bit more confused, let me say that even Josh Bloch, who wrote much of the JRE, said that he prefers not to use clone():<BR/><BR/>http://www.artima.com/intv/blochP.html<BR/><BR/>He suggests to workaround clone()'s problems by calling constructors directly, which beats polymorphism. No wonder we end up with (horrible) factory methods and dependency injection frameworks.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-90586358674210351022008-12-07T19:30:00.000+02:002008-12-07T19:30:00.000+02:00One more question. Why protected on the clone meth...One more question. Why protected on the clone method?<BR/><BR/>Is there some logic to all of this or were the guys at Sun just smoking something at the time :)Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-77659686952770238922008-12-07T19:28:00.000+02:002008-12-07T19:28:00.000+02:00This comment has been removed by the author.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-6022410072068213372008-12-07T19:17:00.000+02:002008-12-07T19:17:00.000+02:00OK. I get it now. So its not the deep copy thing, ...OK. I get it now. So its not the deep copy thing, you can do this yourself if you wish. Its all this nonsense with the marker interface and checked exceptions making everything very verbose.<BR/><BR/>Well they do say your compiler is your friend. I guess its like in real life where some friends can be bloody annoying :)<BR/><BR/>Paul.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-6328133780295006582008-12-07T18:57:00.000+02:002008-12-07T18:57:00.000+02:00Hi Paul,That's why I said "let's assume only primi...Hi Paul,<BR/><BR/>That's why I said "let's assume only primitives, Strings and array fields". Those get cloned by the JVM. The rest needs to be done by us, otherwise both old and new objects will point at the same object. BTW there will be no exception thrown, just shallow copy. So in real life clone() method is normally not as trivial as I showed. Nonetheless it suffers from the same problems wrt exceptions, casting etc.Yardenahttps://www.blogger.com/profile/15649241856669571499noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-64996070654058286522008-12-07T17:23:00.000+02:002008-12-07T17:23:00.000+02:00Hi Yardena,Looking in the JDK it looks as though t...Hi Yardena,<BR/><BR/>Looking in the JDK it looks as though the clone operation in Object performs a shallow copy. So the object being cloned can only contain immutable objects if it is to be properly copied. If this is true then the object can implement the Clone marker interface and make a call to super.clone() when overriding clone() (which I guess is a call to the method that does the shallow copy in Object).<BR/><BR/>If your object contains mutable objects then a shallow copy is no good, you need a deep copy. I can't see why you just can't implement a deep copy yourself using recursion, but I think the idea is that you should not implement Clonable and Object will through a CloneNotSupportedException if someone tries to clone you.<BR/><BR/>Confused? So am I :) But it does appear to be all about state as I guessed.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-62158850977214357702008-12-07T17:19:00.000+02:002008-12-07T17:19:00.000+02:00Hi Paul,Regarding JavaFX script (former F3) you pr...Hi Paul,<BR/><BR/>Regarding JavaFX script (former F3) you probably have already seen https://openjfx.dev.java.net and http://javafx.com There are indeed no papers or tech reports, as far as I can see.Yardenahttps://www.blogger.com/profile/15649241856669571499noreply@blogger.comtag:blogger.com,1999:blog-8866592669665585195.post-10959563140265862432008-12-07T16:54:00.000+02:002008-12-07T16:54:00.000+02:00Hi Yardena,A very clear explanation. I wonder why ...Hi Yardena,<BR/><BR/>A very clear explanation. I wonder why they felt the need to put a CloneNotSupportedException on the interface? And of course making it checked was just silly.<BR/><BR/>My guess is that it has something to do with state. Without state you can do all this compile time checking stuff, which is why it works well with FP languages like Haskell. When you add state though the compiler has a hard time knowing what to do.<BR/><BR/>Interestingly OO is all about encapsulated state. So how do the two (static checks and state) go together? I think they don't.<BR/><BR/>Sun has a new language out called F3. It is part of JavaFX. It seems to be functional at the core, but supports OO too. I haven't been able to find a single technical paper on the language by Sun. All thats out there is marketing blurb.<BR/><BR/>It would be interesting to know whether they have avoided these pitfalls this time around or just perpetuated the same.<BR/><BR/>Another thing I've been looking for is a clear explanation of category theory. This is the mathematical underpinnings of all this type theory stuff. Maths doesn't like state either. In maths when you assign something to something else its immutable and doesn't change behind your back :)<BR/><BR/>So two things I'm on the look out for. A paper on F3 and a simple explanation of category theory. If you've stumbled on either on your travels please let me know.<BR/><BR/>Cheers,<BR/><BR/>Paul.Paul Beckfordhttps://www.blogger.com/profile/16046651614960778254noreply@blogger.com