Category Archives: Java 8

Typeclasses in Java 8

Java 8 doesn’t have implicits (for which much thanks will be given in some quarters), which makes it difficult to create typeclasses in a Scala(z)ish fashion. This is one possible compromise.

What’s New In Octarine

Octarine is now at version 0.5, and has been enhanced with New Stuff:


Transform records (and anything else you have extractors/lenses for) with a fluent mapping DSL.


When you have a bean, but want a record, and your key names map (or can be mapped) reflectively onto bean property names:

Reflective JSON serialisation

You lazy so-and-so, you.

Serialisation/deserialisation of maps

Sometimes the “keys” in a JSON array are dynamic values, such as ids, rather than static property names. In that case, you need to be able to serialise/deserialise a map of values rather than a record. The serialisation/deserialisation libraries have been revamped to support this, and a variety of other cases (lists of maps of lists of records, etc.)


An Extractor<S, T> may be seen as a partial function from S to T: it can only “extract” a value of type T from a value of type S if such a value (or the material from which one can be created) is present. In Octarine, an Extractor<T, V> is a cross between a Function<T, Optional<V>> and a Predicate<T> . It has three methods:

  • V extract(T source) – extracts a value of type V directly from the source (or fails with an exception).
  • Optional<V> apply(T source) – returns either a value of type V extracted from the source and wrapped in an Optional, or Optional.empty if no such value is available.
  • boolean test(T source) – returns true if the source contains the kind of value that we want, and false otherwise.

The obvious example is a Record , which might or might not contain a value for a given Key<T> . We have:

We can enhance extractors with predicates to look for values matching additional criteria besides existence – for example:

This makes them useful when composing tests on a record:

Which in turn makes them useful when filtering a collection of records:

Any OptionalLens<T, V> in Octarine is also an Extractor<T, V> , and any plain old Lens<T, V> can be turned into an Extractor<T, V> by calling Lens::asOptional on it.


Joink is a library for joining together collections of Java 8 objects in memory.

Here’s what that looks like:

Currently supported: inner, outer, left-outer and right-outer joins, as well as many-to-one, one-to-many and one-to-one joins (“strict”, which enforces uniqueness, and non-strict which doesn’t).

Soon to come: Octarine integration.

Monoidal FizzBuzz

See the whole thing on github.

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).

Higher-Order FizzBuzz

Clojure (paste into an instarepl to see outputs):

Java 8:

Conclusion: Java 8 is an acceptable functional programming language.