Enumerables

The EnumJ library needs one small addition before going public: an Enumerable<E> interface.

Enumerator<E> versus Enumerable<E>

As I mentioned in a previous post, Enumerator<E> is like Iterator<E> but endowed with many methods that make enumerators look a lot like Java 8 streams. In addition and unlike streams, enumerators exhibit high composability, shareability and fault tolerance.
All is great, but with one caveat: they don’t repeat (streams do the same). Once you finish enumerating, there is no way to reuse the enumerator, it’s dead forever.
True, it is possible to re-generate the enumerator from the same source and it is also possible to rebuild the pipeline, but what if both the source and the pipeline are unknown? What if all we get is a single Enumerator<E> object>? In such case, it is not possible to re-enumerate the same sequence again.
Enumerable<E> solves this conundrum. This interface extends Iterable<E> and defines the iterator() method in terms of a new method called enumerator():

public interface Enumerable<E> extends Iterable<E> {

    @Override
    public default Iterator<E> iterator() {
        return enumerator();
    } 

    public Enumerator<E> enumerator(); }

Implementation details

In addition to replacing iterator() with enumerator(), the Enumerable<E> interface will feature the same composability that Enumerator<E> enjoys: map(), filter() and the like will be part of its portfolio of methods and it will have the same degree of composablity as Enumerator<E>. This means that, for example, applying one hundred thousand concatenations will not overflow the stack when the iterator is being returned.

Late binding

I’ve just implemented support for late binding in the EnumJ library. This paves the way for enumerator serialization which, in turn, will make possible remote and/or distributed enumerations.

The problem

Usually, when we enumerate, we know what we enumerate upon. This is materialized in the EnumJ library by the Enumerator.of() kind of methods. They receive an iterator, iterable, enumeration, stream or spliterator as parameter.

But what if, at the time of pipeline construction, we don’t have the source ready? In this case we have the option to provide the source of enumeration lazily and the methods Enumerator.ofLazyIterator(), Enumerator.ofLazyIterable(), … etc., give us some form of late-binding.

It gets more complicated: what if the source of information is completely unknown when we build up the pipeline? Lazy inputs don’t help because the input supplier must know what iterator to supply lazily.

Here’s where late binding comes into play.

The solution

The EnumJ library now exposes a LateBindingEnumerator<E> class which implements Enumerator<E> and has two more methods:

Fourteen minutes

This past week I’ve given two small talks on the subject of Enumerators in Java 8 at two meetups organised by the London Java Community. Each speech was meant to be about seven minutes, I largely satisfied that limit.

You can watch the video on the first talk here (a free SkillsMatter account may be required). The slides of the second talk exist here.

Enumerators from Marius Filip

EnumJ Doc

I wrote a previous post about my library for enumerators. I explained that enumerators are highly compose-able iterators exhibiting properties that Java 8 streams currently do not have.

In a later post I showed how to use enumerators to generate large amounts of test data, with such a degree of variety that we can come close to guaranteeing our software for a given period of time.

Today I’ve made a small leap forward: I’ve finished the first draft of EnumJ javadocs which I’ve placed on BitBucket. I do not disclose the source code yet; because of late changes, I am not 100% code coverage anymore.

But the library works and it works rather well. It will find its place quite soon on GitHub (like any proper open source project) and its binary will (hopefully) find a way to Maven Central.

Till then, enjoy the EnumJ documentation.