I have a github account where my various open source code projects are kept.

In particular, I’m the author of Octarine, a Java 8 library for working with records, the manifesto of which is as follows:

Octarine is a Java 8 library for working with data at the edges of your system: records that are loaded from CSV files, deserialised from JSON messages sent over HTTP, or retrieved from databases.

Traditionally, records in Java have been represented by Beans: classes which carry a collection of mutable properties, where each property has a getter method to read it, and a setter method to write it. Bean objects have no “behaviour”, in the sense in which objects in Object-Oriented Programming are said to bundle data and behaviour together. They are degenerate objects.

Code that works with Beans is often ugly and repetitive, littered with null-checks (because a property that hasn’t been set with a setter can always be null), and hampered by the simultaneous verbosity and inflexibility of the Bean protocol. Unit tests for such code are haunted by a sense of their own pointlessness. Anyone who’s spent significant time writing “Enterprise” Java in which the Bean pattern predominates will at some point have asked themselves: “why am I wasting my time with this crap?”

There is a better way. Actually there are several better ways; Octarine provides an implementation of one of them.

Octarine favours:

• Concision – end-user code is concise, readable and free of boilerplate.

• Tolerance – code that works with records should be forgiving in what it accepts, using schemas and pattern-matching to select and process records that satisfy its requirements.

• Immutability – records are immutable by default.

• Composability – keys can be composed to form paths into nested records.

• Transparency – no “magic” required – especially tricks with reflection and dynamic proxies.