[ Seminars ] [ Seminars on CD ROM ] [ Consulting ]
In many programming languages you can use
that language’s “regular” way to pass objects around, and most
of the time everything works fine. But it always seems that there comes a point
at which you must do something irregular and suddenly things get a bit more
complicated (or in the case of C++, quite complicated). Java is no exception,
and it’s important that you understand exactly what’s happening as
you pass objects around and manipulate them. This appendix will provide that
insight.
[ Add Comment ]
Another way to pose the question of this
appendix, if you’re coming from a programming language so equipped, is
“Does Java have
pointers?” Some have claimed that pointers are hard and dangerous and
therefore bad, and since Java is all goodness and light and will lift your
earthly programming burdens, it cannot possibly contain such things. However,
it’s more accurate to say that Java has pointers; indeed, every object
identifier in Java (except for primitives) is one of these pointers, but their
use is restricted and guarded not only by the compiler but by the run-time
system. Or to put it another way, Java has pointers, but no pointer arithmetic.
These are what I’ve been calling “references,” and you can
think of them as “safety pointers,” not unlike the safety scissors
of elementary school—they aren’t sharp, so you cannot hurt yourself
without great effort, but they can sometimes be slow and tedious.
[ Add Comment ]
When you pass a
reference
into a method, you’re still pointing to the same object. A simple
experiment demonstrates this:
//: appendixa:PassReferences.java
// Passing references around.
public class PassReferences {
static void f(PassReferences h) {
System.out.println("h inside f(): " + h);
}
public static void main(String[] args) {
PassReferences p = new PassReferences();
System.out.println("p inside main(): " + p);
f(p);
}
} ///:~The method toString( ) is
automatically invoked in the print statements, and PassReferences
inherits directly from Object with no redefinition of
toString( ). Thus, Object’s version of
toString( ) is used, which prints out the class of the object
followed by the address where that object is located (not the reference, but the
actual object storage). The output looks like this:
p inside main(): PassReferences@1653748 h inside f(): PassReferences@1653748
You can see that both p and
h refer to the same object. This is far more efficient than duplicating a
new PassReferences object just so that you can send an argument to a
method. But it brings up an important issue.
[ Add Comment ]
Aliasing means that more than one
reference is tied to the same object, as in the above example. The problem with
aliasing occurs when someone writes to that object. If the owners of the
other references aren’t expecting that object to change, they’ll be
surprised. This can be demonstrated with a simple example:
//: appendixa:Alias1.java
// Aliasing two references to one object.
public class Alias1 {
int i;
Alias1(int ii) { i = ii; }
public static void main(String[] args) {
Alias1 x = new Alias1(7);
Alias1 y = x; // Assign the reference
System.out.println("x: " + x.i);
System.out.println("y: " + y.i);
System.out.println("Incrementing x");
x.i++;
System.out.println("x: " + x.i);
System.out.println("y: " + y.i);
}
} ///:~In the line:
Alias1 y = x; // Assign the reference
a new Alias1 reference is created,
but instead of being assigned to a fresh object created with new,
it’s assigned to an existing reference. So the contents of reference
x, which is the address of the object x is pointing to, is
assigned to y, and thus both x and y are attached to the
same object. So when x’s i is incremented in the statement:
[ Add Comment ]
x.i++;
y’s i will be
affected as well. This can be seen in the output:
x: 7 y: 7 Incrementing x x: 8 y: 8
One good solution in this case is to
simply not do it: don’t consciously alias more than one reference to an
object at the same scope. Your code will be much easier to understand and debug.
However, when you’re passing a reference in as an argument—which is
the way Java is supposed to work—you automatically alias because the local
reference that’s created can modify the “outside object” (the
object that was created outside the scope of the method). Here’s an
example:
[ Add Comment ]
//: appendixa:Alias2.java
// Method calls implicitly alias their
// arguments.
public class Alias2 {
int i;
Alias2(int ii) { i = ii; }
static void f(Alias2 reference) {
reference.i++;
}
public static void main(String[] args) {
Alias2 x = new Alias2(7);
System.out.println("x: " + x.i);
System.out.println("Calling f(x)");
f(x);
System.out.println("x: " + x.i);
}
} ///:~The output is:
x: 7 Calling f(x) x: 8
The method is changing its argument, the
outside object. When this kind of situation arises, you must decide whether it
makes sense, whether the user expects it, and whether it’s going to cause
problems.
[ Add Comment ]
In general, you call a method in order to
produce a return value and/or a change of state in the object that the method
is called for. (A method is how you “send a message” to that
object.) It’s much less common to call a method in order to manipulate its
arguments; this is referred to as “calling a method for its
side effects.” Thus, when you create a
method that modifies its arguments the user must be clearly instructed and
warned about the use of that method and its potential surprises. Because of the
confusion and pitfalls, it’s much better to avoid changing the argument.
[ Add Comment ]
If you need to modify an argument during
a method call and you don’t intend to modify the outside argument, then
you should protect that argument by making a copy inside your method.
That’s the subject of much of this appendix.
[ Add Comment ]
To review: All argument passing in Java
is performed by passing references. That is, when you pass “an
object,” you’re really passing only a reference to an object that
lives outside the method, so if you perform any modifications with that
reference, you modify the outside object. In addition:
If you’re
only reading information from an object and not modifying it, passing a
reference is the most efficient form of argument passing. This is nice; the
default way of doing things is also the most efficient. However, sometimes
it’s necessary to be able to treat the object as if it were
“local” so that changes you make affect only a local copy and do not
modify the outside object. Many programming languages support the ability to
automatically make a local copy of the outside object, inside the
method[79]. Java
does not, but it allows you to produce this effect.
[ Add Comment ]
This brings up the terminology issue,
which always seems good for an argument. The term is
“pass by value,” and the meaning depends on
how you perceive the operation of the program. The general meaning is that you
get a local copy of whatever you’re passing, but the real question is how
you think about what you’re passing. When it comes to the meaning of
“pass by value,” there are two fairly distinct
camps:
Having
given both camps a good airing, and after saying “It depends on how you
think of a reference,” I will attempt to sidestep the issue. In the end,
it isn’t that important—what is important is that you
understand that passing a reference allows the caller’s object to be
changed unexpectedly.
[ Add Comment ]
The most likely reason for making a local
copy of an object is if you’re going to modify that object and you
don’t want to modify the caller’s object. If you decide that you
want to make a local copy, you simply use the clone( ) method to
perform the operation. This is a method that’s defined as protected
in the base class Object, and which you must override as public
in any derived classes that you want to clone. For example, the standard
library class ArrayList overrides clone( ), so we can call
clone( ) for ArrayList:
//: appendixa:Cloning.java
// The clone() operation works for only a few
// items in the standard Java library.
import java.util.*;
class Int {
private int i;
public Int(int ii) { i = ii; }
public void increment() { i++; }
public String toString() {
return Integer.toString(i);
}
}
public class Cloning {
public static void main(String[] args) {
ArrayList v = new ArrayList();
for(int i = 0; i < 10; i++ )
v.add(new Int(i));
System.out.println("v: " + v);
ArrayList v2 = (ArrayList)v.clone();
// Increment all v2's elements:
for(Iterator e = v2.iterator();
e.hasNext(); )
((Int)e.next()).increment();
// See if it changed v's elements:
System.out.println("v: " + v);
}
} ///:~The clone( ) method produces
an Object, which must then be recast to the proper type. This example
shows how ArrayList’s clone( ) method does not
automatically try to clone each of the objects that the ArrayList
contains—the old ArrayList and the cloned ArrayList are
aliased to the same objects. This is often called a
shallow copy, since
it’s copying only the “surface” portion of an object. The
actual object consists of this “surface,” plus all the objects that
the references are pointing to, plus all the objects those objects are
pointing to, etc. This is often referred to as the
“web of objects.”
Copying the entire mess is called a
deep copy.
[ Add Comment ]
You can see the effect of the shallow
copy in the output, where the actions performed on v2 affect
v:
v: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] v: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Not trying to clone( ) the
objects contained in the ArrayList is probably a fair assumption because
there’s no guarantee that those objects are
cloneable[80].
[ Add Comment ]
Even though the clone method is defined
in the base-of-all-classes Object, cloning is not automatically
available in every
class[81]. This
would seem to be counterintuitive to the idea that base-class methods are always
available in derived classes. Cloning in Java goes against this idea; if you
want it to exist for a class, you must specifically add code to make cloning
work.
[ Add Comment ]
To prevent default cloneability in every
class you create, the
clone( ) method is
protected in the base class Object. Not only does this mean that
it’s not available by default to the client programmer who is simply using
the class (not subclassing it), but it also means that you cannot call
clone( ) via a reference to the base class. (Although that might
seem to be useful in some situations, such as to polymorphically clone a bunch
of Objects.) It is in effect a way to give you, at compile-time, the
information that your object is not cloneable—and oddly enough most
classes in the standard Java library are not cloneable. Thus, if you
say:
Integer x = new Integer(1);
x = x.clone();You will get, at compile-time, an error
message that says clone( ) is not accessible (since Integer
doesn’t override it and it defaults to the protected version).
[ Add Comment ]
If, however, you’re in a class
derived from Object (as all classes are), then you have permission to
call Object.clone( ) because it’s
protected and you’re an inheritor. The base
class clone( ) has useful functionality—it performs the actual
bitwise duplication of the derived-class object, thus acting as the
common cloning operation. However, you then need to make your clone
operation public for it to be accessible. So, two
key issues when you clone are:
[ Add Comment ]
You’ll
probably want to override clone( ) in any further derived classes,
otherwise your (now public) clone( ) will be used, and that
might not do the right thing (although, since Object.clone( ) makes
a copy of the actual object, it might). The protected trick works only
once—the first time you inherit from a class that has no cloneability and
you want to make a class that’s cloneable. In any classes inherited from
your class the clone( ) method is available since it’s not
possible in Java to reduce the access of a method during derivation. That is,
once a class is cloneable, everything derived from it is cloneable unless you
use provided mechanisms (described later) to “turn off” cloning.
[ Add Comment ]
There’s one more thing you need to
do to complete the cloneability of an object: implement the
Cloneable interface. This
interface is a bit strange, because it’s
empty!
interface Cloneable {}The reason for implementing this empty
interface is obviously not because you are going to upcast to
Cloneable and call one of its methods. The use of interface here
is considered by some to be a “hack” because it’s using a
feature for something other than its original intent. Implementing the
Cloneable interface acts as a kind of a flag, wired into the type
of the class.
[ Add Comment ]
There are two reasons for the existence
of the Cloneable interface. First, you might have an upcast
reference to a base type and not know whether it’s possible to clone that
object. In this case, you can use the instanceof keyword (described in
Chapter 12) to find out whether the reference is connected to an object that can
be cloned:
if(myReference instanceof Cloneable) // ...
The second reason is that mixed into this
design for cloneability was the thought that maybe you didn’t want all
types of objects to be cloneable. So Object.clone( ) verifies that a
class implements the Cloneable interface. If not, it throws a
CloneNotSupportedException exception. So in general, you’re forced
to implement Cloneable as part of support for cloning.
[ Add Comment ]
Once you understand the details of
implementing the clone( ) method, you’re able to create
classes that can be easily duplicated to provide a local copy:
//: appendixa:LocalCopy.java
// Creating local copies with clone().
import java.util.*;
class MyObject implements Cloneable {
int i;
MyObject(int ii) { i = ii; }
public Object clone() {
Object o = null;
try {
o = super.clone();
} catch(CloneNotSupportedException e) {
System.err.println("MyObject can't clone");
}
return o;
}
public String toString() {
return Integer.toString(i);
}
}
public class LocalCopy {
static MyObject g(MyObject v) {
// Passing a reference,
// modifies outside object:
v.i++;
return v;
}
static MyObject f(MyObject v) {
v = (MyObject)v.clone(); // Local copy
v.i++;
return v;
}
public static void main(String[] args) {
MyObject a = new MyObject(11);
MyObject b = g(a);
// Testing reference equivalence,
// not object equivalence:
if(a == b)
System.out.println("a == b");
else
System.out.println("a != b");
System.out.println("a = " + a);
System.out.println("b = " + b);
MyObject c = new MyObject(47);
MyObject d = f(c);
if(c == d)
System.out.println("c == d");
else
System.out.println("c != d");
System.out.println("c = " + c);
System.out.println("d = " + d);
}
} ///:~First of all, clone( ) must
be accessible so you must make it public. Second, for the initial part of
your clone( ) operation you should call the base-class version of
clone( ). The clone( ) that’s being called here is
the one that’s predefined inside Object, and you can call it
because it’s protected and thereby accessible in derived classes.
[ Add Comment ]
Object.clone( ) figures out
how big the object is, creates enough memory for a new one, and copies all the
bits from the old to the new. This is called a
bitwise copy, and is typically what you’d
expect a clone( ) method to do. But before
Object.clone( ) performs its operations, it first checks to see if a
class is Cloneable—that is, whether it implements the
Cloneable interface. If it doesn’t, Object.clone( )
throws a CloneNotSupportedException to indicate
that you can’t clone it. Thus, you’ve got to surround your call to
super.clone( ) with a try-catch block, to catch an exception that
should never happen (because you’ve implemented the Cloneable
interface).
[ Add Comment ]
In LocalCopy, the two methods
g( ) and f( ) demonstrate the difference between the two
approaches for argument passing. g( ) shows passing by reference in
which it modifies the outside object and returns a reference to that outside
object, while f( ) clones the argument, thereby decoupling it and
leaving the original object alone. It can then proceed to do whatever it wants,
and even to return a reference to this new object without any ill effects to the
original. Notice the somewhat curious-looking statement:
v = (MyObject)v.clone();
This is where the local copy is created.
To prevent confusion by such a statement, remember that this rather strange
coding idiom is perfectly feasible in Java because every object identifier is
actually a reference. So the reference v is used to clone( )
a copy of what it refers to, and this returns a reference to the base type
Object (because it’s defined that way in
Object.clone( )) that must then be cast to the proper type.
[ Add Comment ]
In main( ), the difference
between the effects of the two different argument-passing approaches in the two
different methods is tested. The output is:
a == b a = 12 b = 12 c != d c = 47 d = 48
It’s important to notice that the
equivalence tests in Java do not look inside the objects being compared to see
if their values are the same. The
==
and != operators are simply comparing the references. If the
addresses inside the references
are the same, the references are pointing to the same object and are therefore
“equal.” So what the operators are really testing is whether the
references are aliased to the same object!
[ Add Comment ]
What actually happens when
Object.clone( ) is
called that makes it so essential to call
super.clone( ) when
you override clone( ) in your class? The clone( ) method
in the root class is responsible for creating the correct amount of storage and
making the bitwise copy of the bits from the original object into the new
object’s storage. That is, it doesn’t just make storage and copy an
Object—it actually figures out the size of the precise object
that’s being copied and duplicates that. Since all this is happening from
the code in the clone( ) method defined in the root class (that has
no idea what’s being inherited from it), you can guess that the process
involves RTTI to determine the actual object
that’s being cloned. This way, the clone( ) method can create
the proper amount of storage and do the correct bitcopy for that type.
[ Add Comment ]
Whatever you do, the first part of the
cloning process should normally be a call to super.clone( ). This
establishes the groundwork for the cloning operation by making an exact
duplicate. At this point you can perform other operations necessary to complete
the cloning.
[ Add Comment ]
To know for sure what those other
operations are, you need to understand exactly what Object.clone( )
buys you. In particular, does it automatically clone the destination of all the
references? The following example tests this:
//: appendixa:Snake.java
// Tests cloning to see if destination
// of references are also cloned.
public class Snake implements Cloneable {
private Snake next;
private char c;
// Value of i == number of segments
Snake(int i, char x) {
c = x;
if(--i > 0)
next = new Snake(i, (char)(x + 1));
}
void increment() {
c++;
if(next != null)
next.increment();
}
public String toString() {
String s = ":" + c;
if(next != null)
s += next.toString();
return s;
}
public Object clone() {
Object o = null;
try {
o = super.clone();
} catch(CloneNotSupportedException e) {
System.err.println("Snake can't clone");
}
return o;
}
public static void main(String[] args) {
Snake s = new Snake(5, 'a');
System.out.println("s = " + s);
Snake s2 = (Snake)s.clone();
System.out.println("s2 = " + s2);
s.increment();
System.out.println(
"after s.increment, s2 = " + s2);
}
} ///:~A Snake is made up of a bunch of
segments, each of type Snake. Thus, it’s a singly linked list. The
segments are created recursively, decrementing the first constructor argument
for each segment until zero is reached. To give each segment a unique tag, the
second argument, a char, is incremented for each recursive constructor
call.
[ Add Comment ]
The increment( ) method
recursively increments each tag so you can see the change, and the
toString( ) recursively prints each tag. The output
is:
s = :a:b:c:d:e s2 = :a:b:c:d:e after s.increment, s2 = :a:c:d:e:f
This means that only the first segment is
duplicated by Object.clone( ), therefore it does a
shallow copy. If you want the whole snake to be
duplicated—a deep copy—you must perform the
additional operations inside your overridden clone( ).
[ Add Comment ]
You’ll typically call
super.clone( ) in any class derived from a cloneable class to make
sure that all of the base-class operations (including
Object.clone( )) take place. This is followed by an explicit call to
clone( ) for every reference in your object; otherwise those
references will be aliased to those of the original object. It’s analogous
to the way constructors are called—base-class constructor first, then the
next-derived constructor, and so on to the most-derived constructor. The
difference is that clone( ) is not a constructor, so there’s
nothing to make it happen automatically. You must make sure to do it yourself.
[ Add Comment ]
There’s a problem you’ll
encounter when trying to deep copy a composed object. You must assume that the
clone( ) method in the member objects will in turn perform a deep
copy on their references, and so on. This is quite a commitment. It
effectively means that for a deep copy to work you must either control all of
the code in all of the classes, or at least have enough knowledge about all of
the classes involved in the deep copy to know that they are performing their own
deep copy correctly.
[ Add Comment ]
This example shows what you must do to
accomplish a deep copy when dealing with a composed object:
//: appendixa:DeepCopy.java
// Cloning a composed object.
class DepthReading implements Cloneable {
private double depth;
public DepthReading(double depth) {
this.depth = depth;
}
public Object clone() {
Object o = null;
try {
o = super.clone();
} catch(CloneNotSupportedException e) {
e.printStackTrace(System.err);
}
return o;
}
}
class TemperatureReading implements Cloneable {
private long time;
private double temperature;
public TemperatureReading(double temperature) {
time = System.currentTimeMillis();
this.temperature = temperature;
}
public Object clone() {
Object o = null;
try {
o = super.clone();
} catch(CloneNotSupportedException e) {
e.printStackTrace(System.err);
}
return o;
}
}
class OceanReading implements Cloneable {
private DepthReading depth;
private TemperatureReading temperature;
public OceanReading(double tdata, double ddata){
temperature = new TemperatureReading(tdata);
depth = new DepthReading(ddata);
}
public Object clone() {
OceanReading o = null;
try {
o = (OceanReading)super.clone();
} catch(CloneNotSupportedException e) {
e.printStackTrace(System.err);
}
// Must clone references:
o.depth = (DepthReading)o.depth.clone();
o.temperature =
(TemperatureReading)o.temperature.clone();
return o; // Upcasts back to Object
}
}
public class DeepCopy {
public static void main(String[] args) {
OceanReading reading =
new OceanReading(33.9, 100.5);
// Now clone it:
OceanReading r =
(OceanReading)reading.clone();
}
} ///:~DepthReading and
TemperatureReading are quite similar; they both contain only primitives.
Therefore, the clone( ) method can be quite simple: it calls
super.clone( ) and returns the result. Note that the
clone( ) code for both classes is identical.
[ Add Comment ]
OceanReading is composed of
DepthReading and TemperatureReading objects and so, to produce a
deep copy, its clone( ) must clone the references inside
OceanReading. To accomplish this, the result of
super.clone( ) must be cast to an OceanReading object (so you
can access the depth and temperature references).
[ Add Comment ]
Let’s revisit the
ArrayList example from
earlier in this appendix. This time the Int2 class is cloneable, so the
ArrayList can be deep copied:
//: appendixa:AddingClone.java
// You must go through a few gyrations
// to add cloning to your own class.
import java.util.*;
class Int2 implements Cloneable {
private int i;
public Int2(int ii) { i = ii; }
public void increment() { i++; }
public String toString() {
return Integer.toString(i);
}
public Object clone() {
Object o = null;
try {
o = super.clone();
} catch(CloneNotSupportedException e) {
System.err.println("Int2 can't clone");
}
return o;
}
}
// Once it's cloneable, inheritance
// doesn't remove cloneability:
class Int3 extends Int2 {
private int j; // Automatically duplicated
public Int3(int i) { super(i); }
}
public class AddingClone {
public static void main(String[] args) {
Int2 x = new Int2(10);
Int2 x2 = (Int2)x.clone();
x2.increment();
System.out.println(
"x = " + x + ", x2 = " + x2);
// Anything inherited is also cloneable:
Int3 x3 = new Int3(7);
x3 = (Int3)x3.clone();
ArrayList v = new ArrayList();
for(int i = 0; i < 10; i++ )
v.add(new Int2(i));
System.out.println("v: " + v);
ArrayList v2 = (ArrayList)v.clone();
// Now clone each element:
for(int i = 0; i < v.size(); i++)
v2.set(i, ((Int2)v2.get(i)).clone());
// Increment all v2's elements:
for(Iterator e = v2.iterator();
e.hasNext(); )
((Int2)e.next()).increment();
// See if it changed v's elements:
System.out.println("v: " + v);
System.out.println("v2: " + v2);
}
} ///:~Int3 is inherited from Int2
and a new primitive member int j is added. You might think that
you’d need to override clone( ) again to make sure j is
copied, but that’s not the case. When Int2’s
clone( ) is called as Int3’s clone( ), it
calls Object.clone( ), which determines that it’s working with
an Int3 and duplicates all the bits in the Int3. As long as you
don’t add references that need to be cloned, the one call to
Object.clone( ) performs all of the necessary duplication,
regardless of how far down in the hierarchy clone( ) is defined.
[ Add Comment ]
You can see what’s necessary in
order to do a deep copy of an ArrayList: after the ArrayList is
cloned, you have to step through and clone each one of the objects pointed to by
the ArrayList. You’d have to do something similar to this to do a
deep copy of a HashMap.
[ Add Comment ]
The remainder of the example shows that
the cloning did happen by showing that, once an object is cloned, you can change
it and the original object is left untouched.
[ Add Comment ]
When you consider Java’s object
serialization (introduced in Chapter 11), you might observe that an object
that’s serialized and then deserialized is, in effect, cloned.
[ Add Comment ]
So why not use
serialization to perform deep
copying? Here’s an example that compares the two approaches by timing
them:
//: appendixa:Compete.java
import java.io.*;
class Thing1 implements Serializable {}
class Thing2 implements Serializable {
Thing1 o1 = new Thing1();
}
class Thing3 implements Cloneable {
public Object clone() {
Object o = null;
try {
o = super.clone();
} catch(CloneNotSupportedException e) {
System.err.println("Thing3 can't clone");
}
return o;
}
}
class Thing4 implements Cloneable {
Thing3 o3 = new Thing3();
public Object clone() {
Thing4 o = null;
try {
o = (Thing4)super.clone();
} catch(CloneNotSupportedException e) {
System.err.println("Thing4 can't clone");
}
// Clone the field, too:
o.o3 = (Thing3)o3.clone();
return o;
}
}
public class Compete {
static final int SIZE = 5000;
public static void main(String[] args)
throws Exception {
Thing2[] a = new Thing2[SIZE];
for(int i = 0; i < a.length; i++)
a[i] = new Thing2();
Thing4[] b = new Thing4[SIZE];
for(int i = 0; i < b.length; i++)
b[i] = new Thing4();
long t1 = System.currentTimeMillis();
ByteArrayOutputStream buf =
new ByteArrayOutputStream();
ObjectOutputStream o =
new ObjectOutputStream(buf);
for(int i = 0; i < a.length; i++)
o.writeObject(a[i]);
// Now get copies:
ObjectInputStream in =
new ObjectInputStream(
new ByteArrayInputStream(
buf.toByteArray()));
Thing2[] c = new Thing2[SIZE];
for(int i = 0; i < c.length; i++)
c[i] = (Thing2)in.readObject();
long t2 = System.currentTimeMillis();
System.out.println(
"Duplication via serialization: " +
(t2 - t1) + " Milliseconds");
// Now try cloning:
t1 = System.currentTimeMillis();
Thing4[] d = new Thing4[SIZE];
for(int i = 0; i < d.length; i++)
d[i] = (Thing4)b[i].clone();
t2 = System.currentTimeMillis();
System.out.println(
"Duplication via cloning: " +
(t2 - t1) + " Milliseconds");
}
} ///:~Thing2 and Thing4 contain
member objects so that there’s some deep copying going on. It’s
interesting to notice that while Serializable classes are easy to set up,
there’s much more work going on to duplicate them. Cloning involves a lot
of work to set up the class, but the actual duplication of objects is relatively
simple. The results really tell the tale. Here is the output from three
different runs:
Duplication via serialization: 940 Milliseconds Duplication via cloning: 50 Milliseconds Duplication via serialization: 710 Milliseconds Duplication via cloning: 60 Milliseconds Duplication via serialization: 770 Milliseconds Duplication via cloning: 50 Milliseconds
Despite the significant time difference
between serialization and cloning, you’ll also notice that the
serialization technique seems to vary more in its duration, while cloning tends
to be more stable.
[ Add Comment ]
If you create a new class, its base class
defaults to Object, which defaults to noncloneability (as you’ll
see in the next section). As long as you don’t explicitly add
cloneability, you won’t get it.
But you can add it in at any
layer and it will then be cloneable from that layer downward, like
this:
//: appendixa:HorrorFlick.java
// You can insert Cloneability
// at any level of inheritance.
import java.util.*;
class Person {}
class Hero extends Person {}
class Scientist extends Person
implements Cloneable {
public Object clone() {
try {
return super.clone();
} catch(CloneNotSupportedException e) {
// this should never happen:
// It's Cloneable already!
throw new InternalError();
}
}
}
class MadScientist extends Scientist {}
public class HorrorFlick {
public static void main(String[] args) {
Person p = new Person();
Hero h = new Hero();
Scientist s = new Scientist();
MadScientist m = new MadScientist();
// p = (Person)p.clone(); // Compile error
// h = (Hero)h.clone(); // Compile error
s = (Scientist)s.clone();
m = (MadScientist)m.clone();
}
} ///:~Before cloneability was added, the
compiler stopped you from trying to clone things. When cloneability is added in
Scientist, then Scientist and all its descendants are cloneable.
[ Add Comment ]
If all this seems to be a strange scheme,
that’s because it is. You might wonder why it worked out this way. What is
the meaning behind this design?
[ Add Comment ]
Originally, Java was designed as a
language to control hardware boxes, and definitely not with the Internet in
mind. In a general-purpose language like this, it makes sense that the
programmer be able to clone any object. Thus, clone( ) was placed in
the root class Object, but it was a public method so you
could always clone any object. This seemed to be the most flexible approach, and
after all, what could it hurt?
[ Add Comment ]
Well, when Java was seen as the ultimate
Internet programming language, things changed. Suddenly, there are security
issues, and of course, these issues are dealt with using objects, and you
don’t necessarily want anyone to be able to clone your security objects.
So what you’re seeing is a lot of patches applied on the original simple
and straightforward scheme: clone( ) is now protected in
Object. You must override it and implement Cloneable
and deal with the exceptions.
[ Add Comment ]
It’s worth noting that you must use
the Cloneable interface only if you’re going to call
Object’s clone( ), method, since that method checks at
run-time to make sure that your class implements Cloneable. But for
consistency (and since Cloneable is empty anyway) you should implement
it.
[ Add Comment ]
You might suggest that, to remove
cloneability, the
clone( ) method simply be made private, but this won’t
work since you cannot take a base-class method and make it less accessible in a
derived class. So it’s not that simple. And yet, it’s necessary to
be able to control whether an object can be cloned. There are actually a number
of attitudes you can take to this in a class that you design:
Here’s an example that shows the various ways cloning can be implemented and then, later in the hierarchy, “turned off”: [ Add&