One of the greatest challenges facing a designer of an object-oriented computer language is how to handle the object vs. simple type dilemma. Here is the problem. From a conceptually pure point of view, every data type should be an object, and every type should descend from a universal parent object. This makes all data types work the same, with each sharing a common set of inherited traits. The trouble is that making the simple types, such as int or double, into objects can cause a decrease in performance because of the added overhead incurred by the object mechanism. Because the simple types are often used to control loops and conditional statements, this extra overhead would have wide-ranging, negative consequences. The trick is to find the right balance between the “everything is an object” desire and the “performance counts” reality.

Java solves the object, simple type problem in an elegant manner. First, it defines eight simple types: byte, short, int, long, char, float, double, and boolean. These types translate directly into binary values. Thus, a variable of type int can be operated on directly by the CPU without any added overhead. The simple types in Java are as fast and efficient as they are in any other language. Therefore, a for loop controlled by an int runs at full speed, unencumbered by any object-related issues.

Aside from the simple types, all other types in Java are objects that inherit the universal superclass Object. Thus, all other types share inherited functionality. For example, all objects have a toString( ) method because toString( ) is a method defined by Object.

Because simple types are not objects, Java is free to treat objects and nonobjects a bit differently. This is where the real genius of Java’s design becomes apparent. In Java, all objects are accessed through a reference, rather than directly, as is the case for the simple types. Thus, your program never operates on an object directly. By using this approach, several benefits follow, not the least of which is garbage collection. Because all objects are accessed via a reference, garbage collection can be efficiently implemented: when there is no reference to an object, it can be recycled. Another benefit is that an object reference of type Object can refer to any object in the system.

Of course, accessing every object through a reference adds overhead. The reason is that a reference is, essentially, an address (i.e., a pointer). Thus, every object access occurs indirectly, through that address. Although modern CPUs handle indirect accesses efficiently, indirect accesses are not as fast as operating directly on the data itself, as is the case with the simple types.

Although the simple types are quite efficient, there are still times when an object equivalent of a simple type is needed. For example, you might want to create a list of integers at runtime and have those integers recycled (garbage collected) when no longer needed. To handle this type of situation, Java defines the simple type wrappers, such as Integer and Double. These wrappers enable the simple types to participate in the object hierarchy when necessary.

Java’s resolution to the object vs. simple type problem captures the right balance. It allows efficient programs to be written, but at the same time it allows the object model to be implemented without concern about negatively impacting the performance of the simple types.

Remember: this is chapter one of The Art of Java, by Herbert Schildt and James Holmes (McGraw-Hill/Osborne, ISBN 0-07-222971-3, 2003). Check it out at your favorite bookstore today.   Buy this book now.