Java Akka Streams/Sources

Analysis of Iterable interface
An  is a good starting point for understanding Akka Streams. Following is the interface as defined in Java 8, omitting default methods.

We could easily create an anonymous inline implementation that return  ranging from 1 to 10.

The  represents a blueprint for producing a sequence of numbers between 1 and 10. The  only represents potential, the actual work of emitting the integers is yet to be done. We can unleash that potential by putting the  in a for-loop.

The for-loop is semantically equivalent to manually traversing the Iterator. By calling the  method, the blueprint of the   is iteratively built through an   instance. The blueprint of the  can be used many times to create many   instances. But each  instance can only be used once.

This represents a pull technology, where the driving thread synchronously blocks while fetching the next element.

We can make the  unbounded, to return a sequence of all positive integers.

Running  would cause an endless loop. So care must be taken when consuming.

Understanding  serves as a good first step to understanding other streaming technologies. But take note of the limitations:


 * Single threaded.
 * is generally not thread safe.
 * The code blocks while waiting for next element.
 * The  is idle between calls to.

Turning into
There are many implementations of  interface. Our first usage of Akka Streams will be converting an  into a , and then running that source with a materializer.

There are plenty of helper methods on the  class for the creation of sources.

Take a look at the generic types of the  signature. The type  is the element type   in our above code, but what does the type   represent, and why is it  ? The short answer right now is that  is the materialized value. Since we are not using the materialized value, the type is.

You will see that the  is blueprint, much like an   is a blueprint, and that during construction of blueprint we not only process values of type , but also produce a materialized value of type.

Akka Streams is naturally multi-threaded. The traversal of the stream is scheduled on a thread pool managed by the Akka system. The materialized value is constructed on the thread running the source in a graph. This will be relevant, but for our simple, there is no materialized value when converting to an  , so the type   is simply given a placeholder of.

is a class that has a singleton instance with no methods nor properties. Should you ever need this  singleton, you can get it by calling.

Running a
Akka Streams uses the Actor System to process sources within graphs.

We need a. Although the Actor System is strongly related, our focus for this book is Akka Streams. To this end, we will simply show you a shortcut to obtain. Much more consideration should be given in a production environment. As a rule, you should only have one ActorSystem shared by all your Akka Streams.

The following is a good basis for experimentation with JUnit.

Once you have a, you can easily run a source.

You should take a moment to appreciate the above code. Without much effort, processing of source is done on a thread pool managed by the. Notice how the  returns a future. You could do other work on the calling thread while your Akka Stream is running. To coordinate execution, the future is joined, thereby blocking until the Akka Stream is processed.

At this point you may assume that all Akka Streams provide a. Although this is a common pattern, this is actually just the materialized value. You see, we could write equivalent code that more explicitly handles the materialized value.

Getting a little ahead of ourselves, note the  and the intermediate   that has the generic type of the materialized value. Only because our materialized value is  do we get   when running the graph.