3.12 Just Biding Your Time

4.1 What Is an Object?

An object is an entity with four properties:

• It has an identity. An object is not the same object as any other object.

• It has a class. Each object is a member of exactly one class.

• It may have fields. A field is a slot for storing values. All objects of the same class have the same fields. When you alter the fields of an object, it does not affect any other object.

• It may have methods invoked on it. All objects of the same class have the same set of methods to invoke on them.

You can think of a class as a template for objects. When an object is created using the class as a template, we say that the object is an instance of the class. The object has a slot to store the value of each nonstatic field in the class. (Static fields and methods are independent of objects; they are discussed in section 4.10.) Each instance of a class shares the same fields, though the fields may hold different values. If you know the class of an object, then you can be sure that the object has all of the fields in that class.

The class also defines what methods may be invoked on the object. When one of these methods is invoked, the class of the object determines exactly which set of code is executed. There are actually four different kinds of invocation in the JVM, each with different rules about how to select which code is executed when a method is called.

The class definition determines how fields and methods may be accessed. This protection allows the programmer to limit the amount of code that has access to these objects, making programs easier to understand and debug, as well as offering a foundation on which secure systems can be built.

In addition to the four properties described here, each object has a fifth property called a monitor . The monitor is like a lock on the object: only one thread may have possession of the monitor at a time. Monitors are discussed in section 16.3.

4.1.1 Objects and References

Objects are represented by reference s. Think of a reference as a rope attached to the object. It's not the object itself, but you can use it to get to the object. Each reference takes up one slot on the stack or local variable array, just like an int or float .

When drawing pictures of the JVM memory space, we use numbers to represent values of the numeric types. To represent references, we use an arrow pointing into the heap . The heap is where objects are stored. For example, let's say that there is an object of type Wallaby (a kind of smallish kangaroo) in variable 0, the int 7 in variable 1, and the float 2.99792458e8 in variable 2. The JVM memory looks like Figure 4.1 . Variable 0 contains a reference to our object, represented by the arrow into the space labeled "Heap." This object has the class Wallaby . The object points back to the definition of Wallaby in the space labeled "Class definitions." The class definition says that any Wallaby must have two fields: an age and a color. It also has any fields Wallaby inherits from its superclass Marsupial . Because a Marsupial has a name , the Wallaby must also have a name .

In keeping with the definition of Wallaby , the object has three fields: name, age , and color . The age is one of the numeric types, so it shows the numerical value 17. The other two fields are object types. They contain reference s to other objects in the heap.

The name field of the Wallaby contains a reference to an object that is a java/lang/String , which has been abbreviated as String . A String is an object just like any other. The fields of a String are private, so you can't really see them. To avoid making the diagram even more cluttered, we have omitted the details of class String . We will just use the text of the String to represent the String . However, you must remember that it's really an object.

The color field holds a reference to an object of class Color . That object has a name as well, though this name is unrelated to the name of a Marsupial . The name of this color is the String "gray" .

There is a special reference called null . Fields that contain references are initialized to null , which is a member of every class, but it represents no object at all. You can use it wherever you'd use a reference , but don't try to look at its fields or call a method on it. It's represented in a diagram like this:

For example, a newly created Wallaby object looks like this before it is initialized:

4.1.2 Class Names

The Java language allows you to abbreviate class names with the package and import statements. The JVM requires that all classes be fully qualified . This means that you must include the full package name each time you mention the class.

Consider this Java program.

package COM.yourcompany;
import java.io.*;
class Hello
{
   public static void main(String a[])
   {
       PrintStream output = System.out;
       output.println("Hello, world");
   }
}

In this program, the class names in Table 4.1 are used. In the JVM, classes are named with a string of letters , numbers, underscores, and slashes ( / ). This is different from the Java class names, which use periods (.) as separators.

4.1.3 Packages

Packages are a naming convention to assure that classes always have unique names, even if they come from different groups of developers who have never heard of each other. Packages are also used for determining access permissions between classes; classes that are in the same package have more privileges on each other than classes in different packages. A package is a collection of classes with the same names up to the last slash ( / ). For example, the package of java/lang/String is java/lang . An example of how packages work is given in Table 4.2.

In Java, the import statement allows you to use class names without the package names. Thus, the Java name String is really just shorthand for java/lang/String . This abbreviation isn't permitted in the JVM; fully qualified package names are required. This absolves the virtual machine of having to deal with ambiguously named classes. In general, the classes you create should be named after the organization you work for. The established convention for this is to use your Internet domain name, written in reverse:

Table 4.1. Fully qualified class name examples

Table 4.2. Package examples

Class name 1	Class name 2	Same package?
COM/company/Foo	COM/company/Bar	Yes
COM/company/Grape/Soda	COM/company/Cola/Soda	No
EDU/school/Cherry/Soda	EDU/school/Cherry/Cola/Soda	No
java/lang/String	String	No
Oyster	Clam	Maybe

COM/sun	Sun Microsystems
EDU/umd/cs	Computer Science Department, University of Maryland
GOV/nasa	U.S. National Aeronautics and Space Administration

If the package name is omitted, then the class is considered to be part of an "unnamed" package. Your system may have more than one unnamed package. When determining access to fields and methods, two classes in unnamed packages may or may not be treated as being included in the same package; it's up to the JVM implementation to decide.

Many examples in this book use the default unnamed package to make the examples easier to read. It's safe in the context of the book, because it's sitting on a page, not interacting with other classes. The executable code that comes with this book uses the domain-derived package name COM/sootNsmoke and subpackages beneath that. Any code you intend somebody else to use should incorporate a package name that is specific to you.