gives clone has protected access in java.lang.object inspiteof all Objects extending from java.lang.Object. Can anyone shed light on this???
P.S : I passed SCJP 1.4 today with 95 % (58/61) Thankfully this wasnt the question i faced
Regards,
Nathaniel Stoddard
Ranch Hand
Joined: May 29, 2003
Posts: 1258
posted
0
According to the API Javadocs, classes that want to be "cloneable" should override the clone method making it public, and declare to class to implement Cloneable.
Remember that when overriding a method, you cannot make it more restrictive (e.g. override a public method making it private). However, you can override a method making it more visible (e.g. override a protected clone method making it public).
I think the motivation is just to make it so that not ever single Object out there has clone() visible to other classes. Cosmetic, at best, but that's the way it is.
Cloning in Java is extremely broken. In fact, it is the second most broken part of the core API in my opinion, and there are *lots* of broken parts. That is, there is a general consensus that cloning is very much broken, but I take it further to say it's more broken that most things. In any case, the use of cloning (even when implemented correctly) is only justified in a few obscure cases, and it is more abused than not (how about that hey? It's extremely broken, yet people insist on misusing an API that offers so little than it is less than zero).
Part of this brokenness is the declaration of the Object.clone() method as protected. A Cloneable class is supposed to override the method with public access (yes, one of the cloning design flaws, but that's the intention of the API designers). So if you call it on a type that is not supposed to be cloned, you will receive a compile-time error. java.lang.String is one of these classes (it is not intended to be cloned).
In case you're wondering, the worst part of the API is that System.in/err/out are declared final while exposing setIn/Err/Out methods. <quiz>So how is it implemented?</quiz>