Implements extended encoding of objects and strings to and from {@link com.persistit.Key}s and {@link com.persistit.Value}s.

There are three kinds of encoding mechanisms used in Persistit™:

1. Encoding and decoding of objects to and from `Key`s,
2. Specialized encoding and decoding of `java.lang.String`s to and from `Key`s, and
3. Encoding and decoding of objects to and from `Value`s.

These mechanisms are each slightly different because the correct collation of key values depends on the encoding of primitive values and `Objects` into `Key`s, whereas collation is not an issue for the encoding of `Value`s. The encoding of `Key`s also differs from the encoding of `Value`s because although collation is not an issue for `Value`s, generally the kinds of objects serialized into `Value`s will be much more complex than those usefully encoded into `Key`s.

Logic for these two different uses is specified by twp different interfaces, {@link com.persistit.encoding.KeyCoder} and {@link com.persistit.encoding.ValueCoder}. Each of these has methods to translate an `Object` to and from an array of bytes.

The specific `KeyCoder` or `ValueCoder` to use in encoding or decoding a `Key` or `Value` is determined by the current {@link com.persistit.encoding.CoderManager}. Persistit has a singleton `CoderManager` at all times. The {@link com.persistit.DefaultCoderManager} is a simple implementation that permits applications to register a `KeyCoder` and `ValueCoder` implementation for each class that requires extended encoding and decoding.

Note that a `ValueCoder` registered for a given class overrides default serialization behavior for that class. A `ValueCoder` can encode state information from a class that is not marked `java.io.Serializable` or `java.io.Externalizable`. In addition, a `ValueCoder` typically represents the state of an object much more concisely than standard object serialization because all class names are represented by system-wide handles rather than class names. (See the {@link com.persistit.ClassIndex} class for details on how classes are mapped to small integer handles.)

### `KeyRenderer` and `ValueRenderer`

The interfaces {@link com.persistit.encoding.KeyRenderer} and {@link com.persistit.encoding.ValueRenderer} extends `KeyCoder` and `ValueCoder` by adding a `render` method. The purpose is to allow the application to pass a mutable object that the renderer populates with decoded data, rather than creating a new object for each decoded value. This mutable object, called the `target`, may be of a different class than the originally encoded value. It is up to the `KeyRenderer` or `ValueRenderer` implementation to determine whether a target object is a suitable recipient for the decoded data.

This mechanism can be used to retrieve a subset of all the information that was originally encoded as part of a complex object into a simpler "rendition" object. For example, to display the name, sex and date of birth of numerous complex Person objects, the application could define a class called PersonNameSexDob having only those fields. It could then define a `ValueRenderer` registered to the Person class that reads and populates only the three relevant fields and skips the rest. The resulting PersonNameSexDob object could then provide the data for a summarized listing of Person objects.

The {@link com.persistit.DefaultObjectCoder} class provides a convenient implementation of these interfaces. It uses Java reflection to read and write the fields of an object to and from Persistit `Value`s and `Key`s.

Finally, the {@link com.persistit.encoding.ObjectCache} class provides a simple cache for previously loaded objects. Unlike the Persistit buffer pool, `ObjectCache` caches a fully realized object, rather than pages containing byte arrays from which objects can be deserialized. `ObjectCache` is similar to a `java.util.WeakHashMap`, but implements different removal rules that are more appropriate for caching persistent objects.