Octarine vs Rekord: Design Comparison

Rekord is an excellent Java 7 library by my friend and sometime colleague Samir, which overlaps in several respects with my Java 8 library Octarine. The similarities are due both to a common ancestry (we both used to work on a codebase that made extensive use in testing of Nat Pryce’s make-it-easy) and an ongoing process of looking in on each other’s code from time to time to see if there’s anything worth pinching. More generally, I think myself and Samir have been scratching similar itches: we’ve both suffered under the tyrannical reign of Java Beans, and have both wanted to find better ways of dealing with record types in Java.

One major design difference between the two libraries has to do with their approach to type tagging. A Rekord is always a Rekord<T> of some particular type T, and is always constrained to use keys which are connected to that type:

The first type parameter in each of the Key<Sandvich, T> declarations identifies that key as one that can be used when creating Rekords of type Rekord<Sandvich>. This means that common key names that might occur in multiple contexts are kept separate by the type system. This helps you to avoid constructing a Rekord<Sandvich> containing a Key<Hair, Style> field. The Sandvich type acts as a kind of namespace for keys.

In Octarine, a Record is just a Record: it can contain key-value pairs using any keys you like. There is a reason for this. I wanted Octarine to move away altogether from the ORM pattern of mirroring types in a domain (database tables, for example) in the record types that represented values taken from that domain. The reason is that we are often interested in records that span domains; for example, if I join the Person table to the Address table, to get a record that represents a person together with their current address, that record will contain values drawn from the columns of both tables.

With Octarine, it’s quite legitimate to define collections of keys that refer to the columns in different tables, but to compose records that use keys from several such collections. Disambiguation of keys is done by prefixing the key name with the name of the interface it’s defined in, for example:

Where Octarine uses type tags is in validation – given a Schema<T>, you can use it to extract a Valid<T> from a Record. It’s up to the schema to determine which keys are permitted/required, and with what values. Schemas can also be permissive, doing just enough validation to ensure that a record can be used in the expected way, but not objecting to the presence of unfamiliar key-value pairs. This seems to me to be the right way to deal with data at the edges of a system, where code that works with an older version of a protocol should not necessarily fail just because a newer version adds a few extra pieces of information. From the point of view of some code that works with Persons, the presence of some Address fields is neither here nor there.

Among the merits of Rekord’s approach is that it enlists the help of the compiler in making sure that data held in Rekords is coherent: there is a real sense in which a Rekord has a type, even though it is not an instance of that type in the traditional sense. Octarine trades off a bit of safety in the interests of flexibility, but also provides a mechanism for tagging records with types that can be used to verify that they are suitable for particular purposes. There’s no reason why each library could not be extended to support the other’s more/less permissive approach (as Karg does, for example, with its support for both typed and untyped keys).