Implementations of structured values that can be embedded as properties of entity beans. Typically, the classes of this package are taken implementations of AAF record data types, as specified by the interfaces of the record package.

The MAJ implementations of these classes are registered with the {@linkplain tv.amwa.maj.meta.TypeDefinitionRecord record type definition} that represents them. This allows the values to be serialised to and from files and streams.

### Memory management

Whenever a non-primitive value is requested from one of these classes, a copy is made to ensure no side effects occur to the internal representation of the value. Similarly, whenever a non-primitive value is passed to these classes, it is copied before storage internally to avoid side effects. Applications should take care to ensure that the repeated copying of values does not cause memory management issues.

For an example of the memory management behaviour, see {@link tv.amwa.maj.embeddable.PackageID#getPackageIDValue()} and {@link tv.amwa.maj.embeddable.PackageID#setPackageIDValue(byte[])}.

### String representation

Values that have a defined string representation, e.g. a rational representing a half can be written "1/2", will generate this when the `toString()` method is called on them. Classes without an obvious simple representation, such as Timecode, will generate a pseudo XML representation similar that that which appears in Reg-XML.

All classes in this package implement a `parseFactory(String)` method that parses the given string an creates an instance of the defining class. This is used when creating values from strings using the {@linkplain tv.amwa.maj.meta.TypeDefinitionRecord record type definition's} {@link tv.amwa.maj.meta.TypeDefinitionRecord#createValueFromString(String) createValueFromString(String)} method.

### Final classes and methods

The classes and methods of this package are declared final deliberately. Their specification was derived from C struct declarations and their behaviour is tightly specified. Extensions of these classes that introduce different behaviour or a different approach to MAJ API memory management will not be expected by any MAJ API implementing classes.

This does not prevent another developer from creating their own implementation of the MAJ API interfaces. In this case, unexpected behaviour may result.