Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Why is clone() method protected?  RSS feed

 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the "protected" access atribute means access only through subclasses and if Object class is on the top of the hierarchy with all the other classes being its subclasses, why is clone() method protected then? Maybe because sometimes we would need to override it with a clone() that has more-restrictive-than-public atribute? If so, when does such a need arise?
 
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Almost, I think.
Suppose it was public. That means that you can call clone() from any other class. Now - you don't want to do this, because you want to control the call for clone() on your objects.
Also, you can always declare your class final - and that's where you end the inheritance. So - if you can't extend class X - you can't get its clone() method as well.
Nimo.
 
Ranch Hand
Posts: 101
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
clone() is a mystery wrapped in a riddle:
(1) clone() will not function unless class also implements Cloneable
(2) Object itself doesn't implement Cloneable, so you can't invoke clone() directly .. only on a Cloneable sub-class
(3) Even as a sub-class of Object, you can't clone() unless you implement the Cloneable interface, yet the Cloneable interface (like Serializable) has no methods!
Viewed this way, the 'protected' modifier makes sense:-) The bigger picture adds up to a restrictive invocation environment for clone()
since neither cloning nor serialization are not guaranteed to succeed (especially on 'mutable' objects), it is probably healthy to be forced to do an explicit implementation, and deal with exceptions then and there
there's also a security perspective - if you could clone() *all* Object subclasses by default ... security would be, well, pretty messy.
As it is, you have much more control. You can
1. implement Cloneable, and let Object manage the clone() , and just handle exceptions,
2. implement Cloneable, and explicitly manage (what gets cloned and how) in your clone() method
3. passively prohibit cloning of your objects by *not* implementing Cloneable, or
4. actively prohibit cloning by implementing Cloneable and throwing a CloneNotSupportedException in the clone() method

hth
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!