In Maven:
<dependency>
<groupId>com.codepoetics</groupId>
<artifactId>octarine-core</artifactId>
<version>0.17</version>
</dependency>
<!-- If JSON serialisation / deserialisation is required -->
<dependency>
<groupId>com.codepoetics</groupId>
<artifactId>octarine-json</artifactId>
<version>0.17</version>
</dependency>
<dependency>
<groupId>com.codepoetics</groupId>
<artifactId>octarine-test</artifactId>
<version>0.17</version>
<scope>test</scope>
</dependency>
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.
An Octarine Record
is a collection of typed key-value pairs, where the Key
s are special objects that carry information about the types of the values. A Record
can contain values for any keys whatsoever, but the types of the values must match the types of the keys.
Key<String> name = Key.named("name");
Key<Integer> age = Key.named("age");
Record person = Record.of(name.of("Dominic"), age.of(39));
String personName = name.extract(person);
Integer personAge = age.extract(person);
Here we have defined two keys, name
and age
, created a Record
with values defined for both keys, and extracted both values from the record in a type-safe way.
Because a Record
can contain values for any Key
or none, the safe way to read values is via the Key::get
method, which returns an Optional
value:
Optional<String> personName = name.get(person);
int personAge = age.get(person).orElse(0);
You can use the Key::test
method to find out whether a Record
contains a particular Key
:
if (name.test(person)) {
System.out.println(name.extract(person));
}
A Key<T>
is both a Predicate<Record>
which tests for the presence of that key in a Record
, and a Function<Record, Optional<T>>
, which tries to retrieve the corresponding value from the Record
and returns Optional.empty()
if it isn't there. Key::extract
returns the value directly (or throws an exception, if it is absent).
This trio of methods - test
, extract
, apply
- defines an Extractor
, a useful general concept.
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 is present. Any Key<T>
is an Extractor<Record, T>
.
Suppose we have a Record
which we know will contain either a person's name and date of birth, or their social security number. We can use the fact that Key
s are Extractor
s to test which is the case and respond accordingly:
public Optional<Person> getPerson(Record details) {
if (name.test(details) && dob.test(details)) {
return Optional.of(getPersonByNameAndAge(name.extract(record), dob.extract(record)));
} else if (ssn.test(record)) {
return Optional.of(getPersonBySocialSecurityNumber(ssn.extract(record)));
} else {
return Optional.empty();
}
}
This is a common enough thing to want to do that Octarine supports using pattern matching to pick out records having particular keys and extract their values:
public Optional<Person> getPerson(Record details) {
Matching<Record, Person> matching = Matching.build(m ->
m.matching(name, dob, (n, d) -> getPersonByNameAndAge(n, d))
.matching(ssn, s -> getPersonBySocialSecurityNumber(s))
);
return matching.apply(details);
}
Each of the patterns described by a matching
call is tried in turn, until one is found where all of the listed extractors match the record. The values targeted
by those extractors are then handed off to the supplied function. (Octarine supports matching patterns of up to four extractors, with functions of up to four arguments).
Octarine's Record
s are immutable: there is no way to change the key/value pairs of a record once it has been created. However, it is possible to create a copy of a Record
with one or more key/value pairs added or removed:
Record person = Record.of(name.of("Dominic"));
Record personWithAge = person.with(age.of(39));
Record personWithoutAName = personWithAge.without(name);
Alternatively, Key
s themselves act as lenses, getting and setting values:
Record person = Record.of(name.of("Dominic"));
Record personWithAge = age.set(person, Optional.of(39));
Record personWithoutAName = name.set(Optional.empty());
Lenses have the interesting property that they compose, which we'll explore later.
If you really want a mutable record, you can have one.
MutableRecord mutable = Record.of(
Person.name.of("Dominic"),
Person.age.of(39),
Person.favouriteColour.of(Color.RED),
Person.address.of(Address.addressLines.of("13 Rue Morgue", "PO3 1TP"))
).mutable();
mutable.set(Person.age.of(40), Person.favouriteColour.of(Color.GRAY));
mutable.unset(Person.address);
Record immutable = mutable.immutable();
Note however that a MutableRecord
is a mutable copy of an immutable Record
, and cannot be used to mutate the Record
it has cloned.
MutableRecords
remember what they've changed: MutableRecord::added
returns a record containing all added or modified key/value pairs, and MutableRecord::removed
returns a set of all removed keys.
We define keys, schemas, serialisers and deserialisers for two record types, Person
and Address
.
public interface Address {
KeySet mandatoryKeys = new KeySet();
ListKey<String> addressLines = mandatoryKeys.add(ListKey.named("addressLines"));
Key<String> postcode = mandatoryKeys.add(Key.named("postcode"));
Schema<Address> schema = mandatoryKeys::accept;
RecordSerialiser serialiser = RecordSerialiser.builder()
.writeList(addressLines, Serialisers.toString)
.writeString(postcode)
.get();
RecordDeserialiser deserialiser = RecordDeserialiser.builder()
.readList(addressLines, ofString)
.readString(postcode)
.get();
}
public interface Person {
KeySet mandatoryKeys = new KeySet();
Key<String> name = mandatoryKeys.add(Key.named("name"));
Key<Integer> age = mandatoryKeys.add(Key.named("age"));
ValidRecordKey<Address> address = mandatoryKeys.add(ValidRecordKey.named("address", Address.schema));
Schema<Person> schema = (record, validationErrors) -> {
mandatoryKeys.accept(record, validationErrors);
age.get(record).ifPresent(a -> {
if (a < 0) validationErrors.accept("Age must be 0 or greater");
});
};
RecordSerialiser serialiser = RecordSerialiser.builder()
.writeString(name)
.writeInteger(age)
.write(address, Address.serialiser)
.get();
RecordDeserialiser deserialiser = RecordDeserialiser.builder()
.readString(name)
.readInteger(age)
.readValidRecord(address, Address.deserialiser.validAgainst(Address.schema))
.get();
}
There is also a short-hand syntax we can use to define keys
KeySet mandatoryKeys = new KeySet();
Key<String> name = mandatoryKeys.add($("name"));
Key<Integer> age = mandatoryKeys.add($("age"));
ValidRecordKey<Address> address = mandatoryKeys.add($V("address", Address.schema));
We can now read a Person
's details from Json, validate the record against the schema and make test assertions against it, created an updated copy with one value changed, and write the updated copy back out to Json.
@Test public void
deserialise_validate_update_serialise() {
Record record = Person.deserialiser.fromString(
"{\"name\": \"Arthur Putey\",\n" +"" +
" \"age\": 42,\n" +
" \"address\": {\n" +
" \"addressLines\": [\"59 Broad Street\", \"Cirencester\"],\n" +
" \"postcode\": \"RA8 81T\"\n" +
" }\n" +
"}");
assertThat(record, ARecord.validAgainst(Person.schema)
.with(Person.name, "Arthur Putey")
.with(Person.age, 42)
// Chaining keys
.with(Person.address.join(Address.addressLines).join(Path.toIndex(0)), "59 Broad Street")
// Using a sub-matcher
.with(Person.address, ARecord.validAgainst(Address.schema).with(Address.postcode, "RA8 81T")));
Record changed = Person.age.update(
record, age -> age.map(v -> v + 1));
assertThat(Person.serialiser.toString(changed), equalTo(
"{\"name\":\"Arthur Putey\"," +"" +
"\"age\":43," +
"\"address\":{" +
"\"addressLines\":[\"59 Broad Street\",\"Cirencester\"]," +
"\"postcode\":\"RA8 81T\"" +
"}}"));
}