Chapter 6

Using the Object and Class Classes

IN THIS CHAPTER

Using the toString method

Implementing the equals method

Trying out the clone method

Understanding the Class class

In this chapter, you find out how to use two classes of the Java API that are important to object-oriented programming:

• The Object class, which every other class inherits — including all the classes in the Java API and any classes you create yourself
• The Class class, which is used to get information about an object’s type

If I could, I’d plant a huge Technical Stuff icon on this entire chapter. All this stuff is a bit on the technical side, and many Java programmers get by for years without understanding or using it. Still, I recommend that you read this chapter carefully. Even if it all doesn’t sink in, it may help explain why some things in Java don’t work quite the way you think they should, and the information in this chapter may someday help you program your way out of a difficult corner.

The Mother of All Classes: Object

Object is the mother of all classes. In Java, every class ultimately inherits the Object class. This class provides a set of methods that is available to every Java object.

Every object is an Object

Any class that doesn’t have an extends clause implicitly inherits Object. Thus you never have to code a class like this:

public class Product extends Object…

If a subclass has an extends clause that specifies a superclass other than Object, the class still inherits Object. That’s because the inheritance hierarchy eventually gets to a superclass that doesn’t have an extends clause, and that superclass inherits Object and passes it down to all its subclasses.

Suppose you have these classes:

public class Manager extends SalariedEmployee…

public class SalariedEmployee extends Employee…

public class Employee extends Person…

public class Person…

Here the Manager class inherits the Object class indirectly because it inherits SalariedEmployee, which inherits Employee, which inherits Person, which inherits Object.

In Java, creating a class that doesn’t inherit Object is not possible.

Object as a type

If you don’t know or care about the type of an object referenced by a variable, you can specify its type as Object. The following example is perfectly legal:

Object emp = new Employee();

You can’t do anything useful with the emp variable, however, because the compiler doesn’t know that it’s an Employee. If the Employee class has a method named setLastName, the following code doesn’t work:

Object emp = new Employee();

emp.setLastName("Smith"); // error: won't compile

Because emp is an Object, not an Employee, the compiler doesn’t know about the setLastName method.

Note that you could still cast the object to an Employee:

Object emp = new Employee();

((Employee)emp).setLastName("Smith"); // this works

But what’s the point? You may as well make emp an Employee in the first place.

Declaring a variable, parameter, or return type as Object in certain situations, however, does make perfect sense. The Java API provides a set of classes designed to maintain collections of objects. One of the most commonly used of these classes is the ArrayList class, which has a method named add that accepts an Object as a parameter. This method adds the specified object to the collection. Because the parameter type is Object, you can use the ArrayList class to create collections of any type of object. (For more information about the ArrayList class and other collection classes, see Book 4.)

Methods of the Object class

Table 6-1 lists all the methods of the Object class. Ordinarily, I wouldn’t list all the methods of a class; I’d just list the ones that I think are most useful. Because Object is such an important player in the game of object-oriented programming, however, I thought it best to show you all its capabilities, even though some of them are a bit obscure.

TABLE 6-1 Methods of the Object Class

Method	What It Does
protected Object clone()	Returns a copy of this object.
boolean equals(Object obj)	Indicates whether this object is equal to the obj object.
protected void finalize()	Is called by the garbage collector when the object is destroyed.
Class getClass()	Returns a Class object that represents this object’s runtime class.
int hashCode()	Returns this object’s hash code.
void notify()	Is used with threaded applications to wake up a thread that’s waiting on this object.
void notifyAll()	Is used with threaded applications to wake up all threads that are waiting on this object.
String toString()	Returns a String representation of this object.
void wait()	Causes this object’s thread to wait until another thread calls notify or notifyAll.
void wait(Long timeout)	Is a variation of the basic wait method.
void wait(Long timeout, int nanos)	Is yet another variation of the wait method.

I warned you — this entire chapter should have a Technical Stuff icon.

Note: Almost half of these methods (notify, notifyAll, and the three wait methods) are related to threading. You find complete information about those five methods in Book 5, Chapter 1. Here’s the rundown on the remaining six methods:

• clone: This method is commonly used to make copies of objects, and overriding it in your own classes is not uncommon. I explain this method in detail later in this chapter, in the section “The clone Method.”
• equals: This method is commonly used to compare objects. Any class that represents an object that can be compared with another object should override this method. Turn to the section “The equals Method,” later in this chapter, for more info.
• finalize: This method is called when the garbage collector realizes that an object is no longer being used and can be discarded. The intent of this method is to let you create objects that clean up after themselves by closing open files and performing other cleanup tasks before being discarded. But because of the way the Java garbage collector works, there's no guarantee that the finalize method is ever actually called. As a result, this method isn’t commonly used.
• getClass: This method is sometimes used in conjunction with the Class class, which I describe later in this chapter, in the section “The Class Class.”
• hashCode: Every Java object has a hash code, which is an int representation of the class that's useful for certain operations.
• toString: This method is one of the most commonly used methods in Java. I describe it in the section “The toString Method,” later in this chapter.

Primitives aren't objects

I need to note that primitive types, such as int and double, are not objects. As a result, they do not inherit the Object class and don’t have access to the methods listed in the preceding section.

As a result, the following code won’t work:

int x = 50;

String s = x.toString(); // error: won't compile

If you really want to convert an int to a string in this way, you can use a wrapper class such as Integer to create an object from the value and then call its toString method:

String s = new Integer(x).toString(); // OK

Each of the wrapper classes also defines a static toString method, which you can use like this:

String s = Integer.toString(x);

Sometimes, using the compiler shortcut that lets you use primitive types in string concatenation expressions is easier:

String s = "" + x;

Here the int variable x is concatenated with an empty string.

The point of all this is that primitive types aren’t objects, so they don’t inherit anything from Object. If you want to treat a primitive value as an object, you can use the primitive type’s wrapper class (as I describe in Book 2, Chapter 2).

The toString Method

The toString method returns a String representation of an object. By default, the toString method returns the name of the object’s class plus its hash code. In the sections that follow, I show you how to use the toString method and how to override it in your own classes to create more useful strings.

Using toString

Here’s a simple program that puts the toString method to work:

public class TestToString

{

public static void main(String[] args)

{

Employee emp = new Employee("Martinez",

"Anthony");

System.out.println(emp.toString());

}

}

class Employee

{

private String lastName;

private String firstName;

public Employee(String lastName, String firstName)

{

this.lastName = lastName;

this.firstName = firstName;

}

}

This code creates a new Employee object; then the result of its toString method is printed to the console. When you run this program, the following line is printed on the console:

Employee@82ba41

Note: The hash code — in this case, 82ba41 — will undoubtedly be different on your system.

It turns out that the explicit call to toString isn’t really necessary in this example. I could just as easily have written the second line of the main method like this:

System.out.println(emp);

That’s because the println method automatically calls the toString method of any object you pass it.

Overriding toString

The default implementation of toString isn’t very useful in most situations. You don’t really learn much about an Employee object by seeing its hash code, for example. Wouldn’t it be better if the toString method returned some actual data from the object, such as the employee’s name?

To do that, you must override the toString method in your classes. In fact, one of the basic guidelines of object-oriented programming in Java is to always override toString. Here’s a simple program with an Employee class that overrides toString:

public class TestToString

{

public static void main(String[] args)

{

Employee emp = new Employee("Martinez",

"Anthony");

System.out.println(emp.toString());

}

}

class Employee

{

private String lastName;

private String firstName;

public Employee(String lastName, String firstName)

{

this.lastName = lastName;

this.firstName = firstName;

}

public String toString()

{

return "Employee["

+ this.firstName + " "

+ this.lastName + "]";

}

}

When you run this program, the following line is displayed on the console:

Employee[Anthony Martinez]

Note that the output consists of the class name followed by some data from the object in brackets. This convention is common in Java programming.

The only problem with the preceding example is that the class name is hard-coded into the toString method. You can use the getClass method to retrieve the actual class name at runtime:

public String toString()

{

return this.getClass().getName() + "["

+ this.firstName + " "

+ this.lastName + "]";

}

Here the getClass method returns a Class object that represents the class of the current object. Then the Class object’s getName method is used to get the actual class name. (You discover more about the Class object later in this chapter.)

The equals Method

Testing objects to see whether they are equal is one of the basic tasks of any object-oriented programming language. Unfortunately, Java isn’t very good at it. Consider this program:

public class TestEquality1

{

public static void main(String[] args)

{

Employee emp1 = new Employee(

"Martinez", "Anthony");

Employee emp2 = new Employee(

"Martinez", "Anthony");

if (emp1 == emp2)

System.out.println(

"These employees are the same.");

else

System.out.println(

"These are different employees.");

}

}

class Employee

{

private String lastName;

private String firstName;

public Employee(String lastName, String firstName)

{

this.lastName = lastName;

this.firstName = firstName;

}

}

Here the main method creates two Employee objects with identical data and then compares them. Alas, the comparison returns false. Even though the Employee objects have identical data, they’re not considered to be equal because the equality operator (==) compares the object references, not the data contained by the objects. Thus the comparison returns true only if both emp1 and emp2 refer to the same instance of the Employee class.

If you want to create objects that are considered to be equal if they contain identical data, you have to do two things:

• Compare them with the equals method rather than the equality operator.
• Override the equals method in your class to compare objects based on their data.

The following sections describe both of these steps.

Using equals

To test objects using the equals method rather than the equality operator, you simply rewrite the comparison expression like this:

if (emp1.equals(emp2))

System.out.println("These employees are equivalent.");

else

System.out.println

("These are different employees.");

Here, the equals method of emp1 is used to compare emp1 with emp2.

By default, the equals operator (inherited from the Object class) returns the same result as the equality operator. So just replacing == with the equals method doesn’t have any effect unless you also override the equals method, as explained in the next section.

Which object’s equals method you use shouldn’t matter. Thus the if statement shown here returns the same result:

if (emp2.equals(emp1))

System.out.println("These employees are the same.");

else

System.out.println

("These are different employees.");

Note that I said it shouldn’t matter. Whenever you override the equals method, you’re supposed to make sure that comparisons work in both directions. Sloppy programming, however, sometimes results in equals methods where a equals b but b doesn’t equal a. Be on your toes.

Overriding the equals method

You can override the equals method so that objects can be compared based on their values. At the surface, you might think this is easy to do. You could be tempted to write the equals method for the Employee class like this:

// warning -- there are several errors in this code!

public boolean equals(Employee emp)

{

if (this.getLastName().equals(emp.getLastName())

&& this.getFirstName().equals(emp.getFirstName()))

return true;

else

return false;

}

The basic problem with this code — and the challenge of coding a good equals method — is that the parameter passed to the equals method must be an Object, not an Employee. That means that the equals method must be prepared to deal with anything that comes its way. Someone might try to compare an Employee object with a Banana object, for example, or with a null. The equals method must be prepared to deal with all possibilities.

Specifically, the Java API documentation says that whenever you override the equals method, you must ensure that the equals method meets five specific conditions. Here they are, quoted right out of the API documentation:

• It is reflexive. For any non-null reference value x, x.equals(x) should return true.
• It is symmetric. For any non-null reference values x and y, x.equals(y) should return true if — and only if — y.equals(x) returns true.
• It is transitive. For any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, x.equals(z) should return true.
• It is consistent. For any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided that no information used in equals comparisons on the objects is modified.
• For any non-null reference value x, x.equals(null) should return false.

Sound confusing? Fortunately, it’s not as complicated as it seems at first. You can safely ignore the transitive rule, because if you get the other rules right, this one happens automatically. The consistency rule basically means that you return consistent results. As long as you don’t throw a call to Math.random into the comparison, that shouldn’t be a problem.

Here’s a general formula for creating a good equals method (assume that the parameter is named obj):

1. Test the reflexive rule.

   Use a statement like this:

   if (this == obj)

   return true;

   In other words, if someone is silly enough to see whether an object is equal to itself, it returns true.

2. Test the non-null rule.

   Use a statement like this:

   if (obj == null)

   return false;

   Null isn’t equal to anything.

3. Test that obj is of the same type as this.

   You can use the getClass method to do that, like this:

   if (this.getClass() != obj.getClass())

   return false;

   The two objects can’t possibly be the same if they aren’t of the same type. (It may not be apparent at first, but this test is required to fulfill the symmetry rule — that if x equals y, y must also equal x.)

4. Cast obj to a variable of your class; then compare the fields you want to base the return value on, and return the result.

   Here’s an example:

   Employee emp = (Employee) obj;

   return this.lastName.equals(emp.getLastName())

   && this.firstname.equals(emp.getFirstName());

   Notice that the field comparisons for the String values use the equals method rather than ==. This is because you can’t trust == to compare strings. If you need to compare primitive types, you can use ==. But you should use equals to compare strings and any other reference types.

Putting it all together, Listing 6-1 shows a program that compares two Employee objects by using a properly constructed equals method.

LISTING 6-1 Comparing Objects

public class TestEquality2

{

public static void main(String[] args)

{

Employee emp1 = new Employee(→5

"Martinez", "Anthony");

Employee emp2 = new Employee(→7

"Martinez", "Anthony");

if (emp1.equals(emp2))→9

System.out.println(

"These employees are the same.");

else

System.out.println(

"These are different employees.");

}

}

class Employee→18

{

private String lastName;

private String firstName;

public Employee(String lastName, String firstName)

{

this.lastName = lastName;

this.firstName = firstName;

}

public String getLastName()

{

return this.lastName;

}

public String getFirstName()

{

return this.firstName;

}

public boolean equals(Object obj)→39

{

// an object must equal itself

if (this == obj)→42

return true;

// no object equals null

if (obj == null)→46

return false;

// objects of different types are never equal

if (this.getClass() != obj.getClass())→50

return false;

// cast to an Employee, then compare the fields

Employee emp = (Employee) obj;→54

return this.lastName.equals(emp.getLastName())→55

&& this.firstName.equals(emp.getFirstName());

}

}

Following are some noteworthy points in this listing:

• →5 Creates an Employee object with the name Anthony Martinez.
• →7 Creates another Employee object with the name Anthony Martinez.
• →9 Compares the two Employee objects by using the equals method.
• →18 The Employee class.
• →39 The overridden equals method.
• →42 Returns true if the same object instances are being compared. This meets the first equality test: that an object must always be equal to itself.
• →46 Returns false if the object being compared is null. This meets the last equality test: that nothing is equal to null.
• →50 Returns false if the object being compared isn’t of the correct type. This helps ensure the symmetry test: that if x equals y, y must equal x.
• →54 Having slid through the other tests, you can assume that you’re comparing two different Employee objects, so the next step is to cast the other object to an Employee.
• →55 Having cast the other object to an Employee, the two fields (lastName and firstName) are compared, and the result of the compound comparison is returned.

The clone Method

Cloning refers to the process of making an exact duplicate of an object. Unfortunately, this process turns out to be a pretty difficult task in an object-oriented language such as Java. You’d think that cloning would be as easy as this:

Employee emp1 = new Employee("Stewart", "Martha");

Employee emp2 = emp1;

This code doesn’t make a copy of the Employee object at all, however. Instead, you now have two variables that refer to the same object, which usually isn’t what you want. Suppose that you execute these statements:

emp1.setLastName("Washington");

emp2.setLastName("Graham");

String lastName = emp1.getLastName();

After these statements execute, does lastName return Washington or Graham? The correct answer is Graham, because both emp1 and emp2 refer to the same Employee object.

By contrast, a clone is an altogether new object that has the same values as the original object. Often you can create a clone manually by using code like this:

Employee emp1 = new Employee("Stewart", "Martha");

Employee emp2 = new Employee();

emp2.setLastName(emp1.getLastName());

emp2.setFirstName(emp1.getFirstName());

emp2.setSalary(emp1.getSalary());

Here a new Employee object is created, and its fields are set to the same values as the original object.

Java provides a more elegant way to create object copies: the clone method, which is available to all classes because it’s inherited from the Object class. As you discover in the following sections, however, the clone method can be difficult to create and use. For this reason, you want to implement it only for those classes that you think can really benefit from cloning.

Implementing the clone method

The clone method is defined by the Object class, so it’s available to all Java classes, but clone is declared with protected access in the Object class. As a result, the clone method for a given class is available only within that class. If you want other objects to be able to clone your object, you must override the clone method and give it public access.

Note that the clone method defined by the Object class returns an Object type. That makes perfect sense, because the Object class doesn’t know the type of the class in which you’ll be overriding the clone method. An inconvenient side effect of returning an Object is that whenever you call the clone method for a class that overrides clone, you must cast the result to the desired object type.

Listing 6-2 gives a simple example of a program that clones Employee objects. In a nutshell, this program overrides the clone method for the Employee class: It creates an Employee object, clones it, changes the name of the original Employee object, and prints out both objects to the console.

LISTING 6-2 A Cloning Example

public class CloneTest

{

public static void main(String[] args)

{

Employee emp1 = new Employee(→5

"Martinez", "Anthony");

emp1.setSalary(40000.0);→7

Employee emp2 = (Employee)emp1.clone();→8

emp1.setLastName("Smith");→9

System.out.println(emp1);→10

System.out.println(emp2);→11

}

}

class Employee→15

{

private String lastName;

private String firstName;

private Double salary;

public Employee(String lastName,

String firstName)

{

this.lastName = lastName;

this.firstName = firstName;

}

public String getLastName()

{

return this.lastName;

}

public void setLastName(String lastName)

{

this.lastName = lastName;

}

public String getFirstName()

{

return this.firstName;

}

public void setFirstName(String firstName)

{

this.firstName = firstName;

}

public Double getSalary()

{

return this.salary;

}

public void setSalary(Double salary)

{

this.salary = salary;

}

public Object clone()→58

{

Employee emp;

emp = new Employee(→61

this.lastName, this.firstName);

emp.setSalary(this.salary);→63

return emp;→64

}

public String toString()

{

return this.getClass().getName() + "["

+ this.firstName + " "

+ this.lastName + ", "

+ this.salary + "]";

}

}

When you run this program, the following lines appear on the console:

Employee[Anthony Smith, 40000.0]

Employee[Anthony Martinez, 40000.0]

As you can see, the name of the second Employee object was successfully changed without affecting the name of the first Employee object.

The following paragraphs draw your attention to some of the highlights of this program:

• →5 Creates the first Employee object for an employee named Anthony Martinez.
• →7 Sets Mr. Martinez’s salary.
• →8 Creates a clone of the Employee object for Mr. Martinez. Notice that the return value must be cast to an Employee, because the return value of the clone method is Object.
• →9 Changes the last name for the second Employee object.
• →10 Prints the first Employee object.
• →11 Prints the second Employee object.
• →15 The Employee class. This class defines private fields to store the last name, first name, and salary, as well as getter and setter methods for each field.
• →58 Overrides the clone method. Notice that its return type is Object, not Employee.
• →61 Creates a new Employee object, using the last name and first name from the current object.
• →63 Sets the new employee’s salary to the current object’s salary.
• →64 Returns the cloned Employee object.

Using clone to create a shallow copy

In the preceding example, the clone method manually creates a copy of the original object and returns it. In many cases, this is the easiest way to create a clone. But what if your class has a hundred or more fields that need to be duplicated? The chance of forgetting to copy one of the fields is high, and if you add a field to the class later on, you may forget to modify the clone method to include the new field.

Fortunately, you can solve this problem by using the clone method of the Object class directly in your own clone method. The clone method of the Object class can automatically create a copy of your object that contains duplicates of all the fields that are primitive types (such as int and double), as well as copies of immutable reference types — most notably, strings. So if all the fields in your class are either primitives or strings, you can use the clone method provided by the Object class to clone your class.

This type of clone is known as a shallow copy, for reasons that I explain in the next section.

To call the clone method from your own clone method, just specify super.clone(). Before you can do that, however, you must do two things:

• Declare that the class supports the Cloneable interface. The Cloneable interface is a marker interface that doesn’t provide any methods. It simply marks a class as being appropriate for cloning.
• Enclose the call to super.clone() in a try/catch statement that catches the exception CloneNotSupportedException. This exception is thrown if you try to call clone on a class that doesn’t implement the Cloneable interface. Provided that you implement Cloneable, this exception won’t ever happen, but because CloneNotSupportedException is a checked exception, you must catch it.

Here’s an example of an Employee class with a clone method that uses super.clone() to clone itself:

class Employee implements Cloneable

{

// Fields and methods omitted…

public Object clone()

{

Employee emp;

try

{

emp = (Employee) super.clone();

}

catch (CloneNotSupportedException e)

{

return null; // will never happen

}

return emp;

}

}

Notice that this method doesn’t have to be aware of any of the fields declared in the Employee class. This clone method, however, works only for classes whose fields are all either primitive types or immutable objects such as strings.

Creating deep copies

It’s not uncommon for some fields in a class actually to be other objects. The Employee class, for example, might have a field of type Address that’s used to store each employee’s address:

class Employee

{

public Address address;

// other fields and methods omitted

}

If that’s the case, the super.clone() method won’t make a complete copy of the object. The clone won’t get a clone of the address field. Instead, it has a reference to the same address object as the original.

To solve this problem, you must do a deep copy of the Employee object. A deep copy is a clone in which any subobjects within the main object are also cloned or copied. To accomplish this feat, the clone method override first calls super.clone() to create a shallow copy of the object. Then it calls the clone method of each of the subobjects contained by the main object to create clones of those objects. (For a deep copy to work, of course, those objects must also support the clone methods or contain code to copy their values.)

Listing 6-3 shows an example. Here, an Employee class contains a public field named address, which holds an instance of the Address class. As you can see, the clone method of the Employee class creates a shallow copy of the Employee object and then sets the copy’s address field to a clone of the original object’s address field. To make this example work, the Address class also overrides the clone method. Its clone method calls super.clone() to create a shallow copy of the Address object.

LISTING 6-3 Creating a Deep Copy

public class CloneTest2

{

public static void main(String[] args)

{

Employee emp1 = new Employee(→5

"Martinez", "Anthony");

emp1.setSalary(40000.0);

emp1.address = new Address(→8

"1300 N. First Street",

"Fresno", "CA", "93702");

Employee emp2 = (Employee)emp1.clone();→11

System.out.println(→13

"**** after cloning ****\n");

printEmployee(emp1);

printEmployee(emp2);

emp2.setLastName("Smith");→17

emp2.address = new Address(→18

"2503 N. 6th Street",

"Fresno", "CA", "93722");

System.out.println(→22

"**** after changing emp2 ****\n");

printEmployee(emp1);

printEmployee(emp2);

}

private static void printEmployee(Employee e)→28

{

System.out.println(e.getFirstName()

+ " " + e.getLastName());

System.out.println(e.address.getAddress());

System.out.println("Salary: " + e.getSalary());

System.out.println();

}

}

class Employee implements Cloneable→38

{

private String lastName;

private String firstName;

private Double salary;

public Address address;→43

public Employee(String lastName, String firstName)

{

this.lastName = lastName;

this.firstName = firstName;

this.address = new Address();

}

public String getLastName()

{

return this.lastName;

}

public void setLastName(String lastName)

{

this.lastName = lastName;

}

public String getFirstName()

{

return this.firstName;

}

public void setFirstName(String firstName)

{

this.firstName = firstName;

}

public Double getSalary()

{

return this.salary;

}

public void setSalary(Double salary)

{

this.salary = salary;

}

public Object clone()→81

{

Employee emp;

try

{

emp = (Employee) super.clone();→86

emp.address = (Address)address.clone();→87

}

catch (CloneNotSupportedException e)→89

{

return null; // will never happen

}

return emp;→93

}

public String toString()

{

return this.getClass().getName() + "["

+ this.firstName + " "

+ this.lastName + ", "

+ this.salary + "]";

}

}

class Address implements Cloneable→105

{

private String street;

private String city;

private String state;

private String zipCode;

public Address()

{

this.street = "";

this.city = "";

this.state = "";

this.zipCode = "";

}

public Address(String street, String city,

String state, String zipCode)

{

this.street = street;

this.city = city;

this.state = state;

this.zipCode = zipCode;

}

public Object clone()→129

{

try

{

return super.clone();→133

}

catch (CloneNotSupportedException e)

{

return null; // will never happen

}

}

public String getAddress()

{

return this.street + "\n"

+ this.city + ", "

+ this.state + " "

+ this.zipCode;

}

}

The main method in the CloneTest2 class creates an Employee object and sets its name, salary, and address. Then it creates a clone of this object and prints the data contained in both objects. Next, it changes the last name and address of the second employee and prints the data again. Here’s the output that’s produced when this program is run:

**** after cloning ****

Anthony Martinez

1300 N. First Street

Fresno, CA 93702

Salary: 40000.0

Anthony Martinez

1300 N. First Street

Fresno, CA 93702

Salary: 40000.0

**** after changing emp2 ****

Anthony Martinez

1300 N. First Street

Fresno, CA 93702

Salary: 40000.0

Anthony Smith

2503 N. 6th Street

Fresno, CA 93722

Salary: 40000.0

As you can see, the two Employee objects have identical data after they are cloned, but they have different data after the fields for the second employee have been changed. Thus, you can safely change the data in one of the objects without affecting the other object.

The following paragraphs describe some of the highlights of this program:

• →5 Creates an employee named Anthony Martinez.
• →8 Sets the employee’s address.
• →11 Clones the employee (okay, just the object, not the co-worker).
• →13 Prints the two Employee objects after cloning. They should have identical data.
• →17 Changes the second employee’s name.
• →18 Changes the second employee’s address.
• →22 Prints the two Employee objects after changing the data for the second employee. The objects should now have different data.
• →28 A utility method that prints the data for an Employee object.
• →38 The Employee class. Notice that this class implements Cloneable.
• →43 The address field, which holds an object of type Address.
• →81 The clone method in the Employee class.
• →86 Creates a shallow copy of the Employee object.
• →87 Creates a shallow copy of the Address object and assigns it to the address field of the cloned Employee object.
• →89 Catches CloneNotSupportedException, which won’t ever happen because the class implements Cloneable. The compiler requires the try/catch statement here because CloneNotSupportedException is a checked exception.
• →93 Returns the cloned Employee object.
• →105 The Address class, which also implements Cloneable.
• →129 The clone method of the Address class.
• →133 Returns a shallow copy of the Address object.

The Class Class

Okay, class, it’s time for one last class in this chapter: the Class class. The wording might get confusing, so put your thinking cap on.

Every class used by a Java application is represented in memory by an object of type Class. If your program uses Employee objects, for example, there’s also a Class object for the Employee class. This Class object has information not about specific employees but about the Employee class itself.

You’ve already seen how you can get a Class object by using the getClass method. This method is defined by the Object class, so it’s available to every object. Here’s an example:

Employee emp = new Employee();

Class c = emp.getClass();

Note that you have to initialize a variable with an object instance before you can call its getClass method. That’s because the getClass method returns a Class object that corresponds to the type of object the variable refers to, not the type the variable is declared as.

Suppose that an HourlyEmployee class extends the Employee class. Then consider these statements:

HourlyEmployee emp = new Employee();

Class c = emp.getClass();

Here c refers to a Class object for the HourlyEmployee class, not the Employee class.

The Class class has more than 50 methods, but only 2 of them are worthy of your attention:

• getName(): Returns a String representing the name of the class
• getSuperclass(): Returns another Class object representing this Class object’s superclass

If you’re interested in the other capabilities of the Class class, you can always check it out in the Java API documentation.

One of the most common uses of the getClass method is to tell whether two objects are of the same type by comparing their Class objects. This works because Java guarantees that the Class object has only one instance for each different class used by the application. So even if your application instantiates 1,000 Employee objects, there is only one Class object for the Employee class.

As a result, the following code can determine whether two objects are both objects of the same type:

Object o1 = new Employee();

Object o2 = new Employee();

if (o1.getClass() == o2.getClass())

System.out.println("They're the same.");

else

System.out.println("They are not the same.");

In this case, the type of both objects is Employee, so the comparison is true.

To find out whether an object is of a particular type, use the object’s getClass method to get the corresponding Class object. Then use the getName method to get the class name, and use a string comparison to check the class name. Here’s an example:

if (emp.getClass().getName().equals("Employee"))

System.out.println("This is an employee object.");

If all the strung-out method calls give you a headache, you can break the code apart:

Class c = emp.getClass();

String s = c.getName();

if (s.equals("Employee"))

System.out.println("This is an employee object.");

The result is the same.