Another very important aspect of the persistence framework being developed for the UnboundID LDAP SDK for Java is the set of data types that it supports. In order to be able to correctly store and retrieve Java objects in a directory server, the LDAP SDK has to now how to encode Java values to LDAP attributes, and then decode the values of those attributes back to their Java representations. The LDAP SDK provides an abstract
LDAPFieldEncoder class which defines the API needed to achieve this, as well as other things like generating LDAP attribute type definitions for a particular field or method. The
@LDAPFieldSetter annotation types all include elements that allow you to specify the type of encoder that should be used when interacting with the associated field or method.
encoderClass element isn’t provided in the annotation, then the LDAP SDK will use an instance of the
DefaultLDAPFieldEncoder class. This class supports a pretty broad range of data types, including:
In addition, it also supports arrays of all of the above types for dealing with multi-valued attributes. In the future, I intend to add add support for using
java.util.Sets for all of the above types as well, but that’s not in the current implementation, and generics make that a bit tricky.
For most of the above data types, the value stored in the directory server is simply the string representation of the associated primitive or object. However, there are a few special cases:
java.lang.Booleanobjects are always stored using values of “TRUE” or “FALSE” (in all uppercase), as per the LDAP Boolean syntax.
byteobjects are used to represent the raw bytes that comprise the attribute value
charobjects are used to represent the raw characters that comprise the attribute value
java.util.Dateobjects are encoded using the LDAP generalized time syntax
Even though the default field encoder supports a number of primitive types (although it doesn’t support either
char in order to avoid confusion), I would generally recommend that you use the corresponding objects in the
java.lang package instead. The reason for this is that primitives can’t have a
null value, so it’s not possible to distinguish between cases in which there is no value and cases where there is a value that happens to be the same as the default value for that primitive (zero for numeric types and
boolean). If you use the corresponding object types instead, then they can have
null values, and you can use that to determine if a value has been assigned.
If you need to store some other kind of object in the directory that isn’t in this list, then you’ll need to create your own subclass of
LDAPFieldEncoder with the appropriate logic for encoding and decoding values. If this is necessary, then I’d strongly recommend using
DefaultLDAPFieldEncoder as a starting point.