--- Comment #1 from Andreas L. Delmelle <> 2011-01-09 
17:34:33 EST ---
(In reply to comment #0)
> How does clone differ from a copy constructor? 

Mainly in the returned type. The result of a call to a copy constructor will
always be statically typed as the class where the constructor is defined. This
can lead to undesired results if the parameter is an instance of a subclass,
unless either:
a) the copy constructor is overridden in the subclass, which makes it awkward
to use vs. a single clone() method, or
b) the superclass' copy constructor contains some convoluted reflection logic
to test the parameter for its runtime type (but that would not take into
account possible subclasses out of your control)

clone(), on the other hand, is guaranteed to always return an instance of
Object, whose actual runtime type is (recommended to be) identical to that of
the instance for which it is called. In practice, Object.clone() respect this,
so having the Cloneable interface is enough for basic shallow cloning to be
enabled. The key advantage being that in your code it takes only a single
statement to invoke. The Java runtime will sort out which implementation to

> Is it a bad situation to have both a clone method and a copy constructor?
> Is it advisable to delete one of them?

Both have their merits. From the point of view of an internal API, if the class
itself is final or you know in advance precisely which type(s) you need, a set
of copy constructors will generally be more appropriate. From the point of view
of an external API, where you need to accommodate potential subclasses, clone()
would be the way to go.
Looking closer at the code, especially for the AreaTreeObject subclasses,
clone() is only used by the Java2DRenderer, and even then, it is only called
externally on PageViewport. All the other calls to clone() happen internally in
the area package. There seems to be no hard requirement at all to have a public
API to create clones/copies of all the other object classes, so there I would
be more inclined to opt for protected copy constructors, or an optimized set of
static factory-like methods, maybe...?

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to