A Type object is an analogue of a Java class; it allows us to categorize objects, but provides for more fine-grained control over this categorization than would be possible were we to categorize objects based on their Java class alone. See Figure 3.1 for more details; the additional classes shown in this class diagram are discussed below.

Figure 3.1. Class Type.

Class Type implements PoComparable, allowing us to use it in partially ordered data structures.

We have made the simplifying design decision that the Type of an object does not change at run-time. Without this simplification, the state machine for the objects in our framework would be complicated by having to handle "type changed" events.

Notably absent from the contract of class Type is any notion of uniqueness of the of the Type of a given object. On the other hand, any subsystem responsible for returning the Type of an object can and should return at least the appropriate JavaType (see below); effectively, this is a guarantee that there exists a minimum of one Type for any Object.

A developer could, if they so wished, define subclasses of Type which recognize information that is not necessarily representable by an Object; the most obvious example would be a Type associated with a Java primitive data type such as integer. We neither recommend nor discourage this approach, but we note that such a Type may not be very useful, as it would be unable to recognize instances of itself via the Type.isInstance(Object) method.