Learning Reactive Programming With Java 8

Chapter 1. An Introduction to Reactive Programming

Nowadays, the term reactive programming is trending. Libraries and frameworks in various programming languages are emerging. Blog posts, articles and presentations about reactive programming are being created. Big companies, such as Facebook, SoundCloud, Microsoft, and Netflix, are supporting and using this concept. So we, as programmers, are starting to wonder about it. Why are people so excited about reactive programming? What does it mean to be reactive? Would it be helpful in our projects? Should we learn how to use it?

Meanwhile, Java is popular with its multi-threading, speed, reliability, and good portability. It is used for building a wide variety of applications, from search engines, through databases to complex web applications running on server clusters. But Java has bad reputation too—it is very hard to write both concurrent and simple applications using only the built-in tools, and programming in Java requires writing a lot of boilerplate code. Also, if you need to be asynchronous (using futures, for example), you can easily get into "callback hell", which actually holds true for all programming languages.

In other words, Java is powerful and you can create great applications with it, but it won't be easy. The good news is that there is a way to change that, using the reactive style of programming.

This book will present RxJava (https://github.com/ReactiveX/RxJava), an open source Java implementation of the reactive programming paradigm. Writing code using RxJava requires a different kind of thinking, but it will give you the power to create complex logic using simple pieces of well-structured code.

In this chapter, we will cover:

What reactive programming is
Reasons to learn and use this style of programming
Setting up RxJava and comparing it with familiar patterns and structures
A simple example with RxJava

Why should we be reactive?

The easiest way for us to answer this question is to think about the requirements we have while building applications these days.

While 10-15 years ago it was normal for websites to go through maintenance or to have a slow response time, today everything should be online 24/7 and should respond with lightning speed; if it's slow or down, users would prefer an alternative service. Today slow means unusable or broken. We are working with greater volumes of data that we need to serve and process fast.

HTTP failures weren't something rare in the recent past, but now, we have to be fault-tolerant and give our users readable and reasonable message updates.

In the past, we wrote simple desktop applications, but today we write web applications, which should be fast and responsive. In most cases, these applications communicate with a large number of remote services.

These are the new requirements we have to fulfill if we want our software to be competitive. So in other words we have to be:

Modular/dynamic: This way, we will be able to have 24/7 systems, because modules can go offline and come online without breaking or halting the entire system. Additionally, this helps us better structure our applications as they grow larger and manage their code base.
Scalable: This way, we are going to be able to handle a huge amount of data or large numbers of user requests.
Fault-tolerant: This way, the system will appear stable to its users.
Responsive: This means fast and available.

Let's think about how to accomplish this:

We can become modular if our system is event-driven. We can divide the system into multiple micro-services/components/modules that are going to communicate with each other using notifications. This way, we are going to react to the data flow of the system, represented by notifications.
To be scalable means to react to the ever-growing data, to react to load without falling apart.
Reacting to failures/errors will make the system more fault-tolerant.
To be responsive means reacting to user activity in a timely manner.

If the application is event-driven, it can be decoupled into multiple self-contained components. This helps us become more scalable, because we can always add new components or remove old ones without stopping or breaking the system. If errors and failures are passed to the right component, which can handle them as notifications, the application can become more fault-tolerant or resilient. So if we build our system to be event-driven, we can more easily achieve scalability and failure tolerance, and a scalable, decoupled, and error-proof application is fast and responsive to users.

The Reactive Manifesto (http://www.reactivemanifesto.org/) is a document defining the four reactive principles that we mentioned previously. Each reactive system should be message-driven (event-driven). That way, it can become loosely coupled and therefore scalable and resilient (fault-tolerant), which means it is reliable and responsive (see the preceding diagram).

Note that the Reactive Manifesto describes a reactive system and is not the same as our definition of reactive programming. You can build a message-driven, resilient, scalable, and responsive application without using a reactive library or language.

Changes in the application data can be modeled with notifications, which can be propagated to the right handlers. So, writing applications using reactive programming is the easiest way to comply with the Manifesto.

Introducing RxJava

To write reactive programs, we need a library or a specific programming language, because building something like that ourselves is quite a difficult task. Java is not really a reactive programming language (it provides some tools like the java.util.Observable class, but they are quite limited). It is a statically typed, object-oriented language, and we write a lot of boilerplate code to accomplish simple things (POJOs, for example). But there are reactive libraries in Java that we can use. In this book, we will be using RxJava (developed by people in the Java open source community, guided by Netflix).

Downloading and setting up RxJava

You can download and build RxJava from Github (https://github.com/ReactiveX/RxJava). It requires zero dependencies and supports Java 8 lambdas. The documentation provided by its Javadoc and the GitHub wiki pages is well structured and some of the best out there. Here is how to check out the project and run the build:

$ git clone git@github.com:ReactiveX/RxJava.git
$ cd RxJava/
$ ./gradlew build

Of course, you can also download the prebuilt JAR. For this book, we'll be using version 1.0.8.

If you use Maven, you can add RxJava as a dependency to your pom.xml file:

<dependency>
  <groupId>io.reactivex</groupId>
  <artifactId>rxjava</artifactId>
  <version>1.0.8</version>
</dependency>

Alternatively, for Apache Ivy, put this snippet in your Ivy file's dependencies:

<dependency org="io.reactivex" name="rxjava" rev="1.0.8" />

If you use Gradle instead, update your build.gradle file's dependencies as follows:

dependencies {
  ...
  compile 'io.reactivex:rxjava:1.0.8'
  ...
}

Note

The code examples and programs accompanying this book can be built and tested with Gradle. It can be downloaded from this Github repository: https://github.com/meddle0x53/learning-rxjava.

Now, let's take a peek at what RxJava is all about. We are going to begin with something well known, and gradually get into the library's secrets.

Comparing the iterator pattern and the RxJava Observable

As a Java programmer, it is highly possible that you've heard or used the Iterator pattern. The idea is simple: an Iterator instance is used to traverse through a container (collection/data source/generator), pulling the container's elements one by one when they are required, until it reaches the container's end. Here is a little example of how it is used in Java:

List<String> list = Arrays.asList("One", "Two", "Three", "Four", "Five"); // (1)

Iterator<String> iterator = list.iterator(); // (2)

while(iterator.hasNext()) { // 3
  // Prints elements (4)
  System.out.println(iterator.next());
}

Every java.util.Collection object is an Iterable instance which means that it has the method iterator(). This method creates an Iterator instance, which has as its source the collection. Let's look at what the preceding code does:

We create a new List instance containing five strings.
We create an Iterator instance from this List instance, using the iterator() method.
The Iterator interface has two important methods: hasNext() and next(). The hasNext() method is used to check whether the Iterator instance has more elements for traversing. Here, we haven't begun going through the elements, so it will return True. When we go through the five strings, it will return False and the program will proceed after the while loop.
The first five times, when we call the next() method on the Iterator instance, it will return the elements in the order they were inserted in the collection. So the strings will be printed.

In this example, our program consumes the items from the List instance using the Iterator instance. It pulls the data (here, represented by strings) and the current thread blocks until the requested data is ready and received. So, for example, if the Iterator instance was firing a request to a web server on every next() method call, the main thread of our program would be blocked while waiting for each of the responses to arrive.

RxJava's building blocks are the observables. The Observable class (note that this is not the java.util.Observable class that comes with the JDK) is the mathematical dual of the Iterator class, which basically means that they are like the two sides of the same coin. It has an underlying collection or computation that produces values that can be consumed by a consumer. But the difference is that the consumer doesn't "pull" these values from the producer like in the Iterator pattern. It is exactly the opposite; the producer 'pushes' the values as notifications to the consumer.

Here is an example of the same program but written using an Observable instance:

List<String> list = Arrays.asList("One", "Two", "Three", "Four", "Five"); // (1)

Observable<String> observable = Observable.from(list); // (2)

observable.subscribe(new Action1<String>() { // (3)
  @Override
  public void call(String element) {
    System.out.println(element); // Prints the element (4)
  }
});

Here is what is happening in the code:

We create the list of strings in the same way as in the previous example.
Then, we create an Observable instance from the list, using the from(Iterable<? extends T> iterable) method. This method is used to create instances of Observable that send all the values synchronously from an Iterable instance (the list in our case) one by one to their subscribers (consumers). We'll look at how the values are sent to the subscribers one by one in Chapter 3, Creating and Connecting Observables, Observers, and Subjects.
Here, we can subscribe to the Observable instance. By subscribing, we tell RxJava that we are interested in this Observable instance and want to receive notifications from it. We subscribe using an anonymous class implementing the Action1 interface, by defining a single method—call(T). This method will be called by the Observable instance every time it has a value, ready to be pushed. Always creating new Action1 instances may seem too verbose, but Java 8 solves this verbosity. We'll learn more about that in Chapter 2, Using the Functional Constructions of Java 8.
So, every string from the source list will be pushed through to the call() method, and it will be printed.

Instances of the RxJava Observable class behave somewhat like asynchronous iterators, which notify that there is a next value their subscribers/consumers by themselves. In fact, the Observable class adds to the classic Observer pattern (implemented in Java—see java.util.Observable, see Design Patterns: Elements of Reusable Object-Oriented Software by the Gang Of Four) two things available in the Iterable type.

The ability to signal the consumer that there is no more data available. Instead of calling the hasNext() method, we can attach a subscriber to listen for a 'OnCompleted' notification.
The ability to signal the subscriber that an error has occurred. Instead of try-catching an error, we can attach an error listener to the Observable instance.

These listeners can be attached using the subscribe(Action1<? super T>, Action1 <Throwable>, Action0) method. Let's expand the Observable instance example by adding error and completed listeners:

List<String> list = Arrays.asList("One", "Two", "Three", "Four", "Five");

Observable<String> observable = Observable.from(list);
observable.subscribe(new Action1<String>() {
  @Override
  public void call(String element) {
    System.out.println(element);
  }
},
new Action1<Throwable>() {
  @Override
  public void call(Throwable t) {
    System.err.println(t); // (1)
  }
},
new Action0() {
  @Override
  public void call() {
    System.out.println("We've finnished!"); // (2)
  }
});

The new things here are:

If there is an error while processing the elements, the Observable instance will send this error through the call(Throwable) method of this listener. This is analogous to the try-catch block in the Iterator instance example.
When everything finishes, this call() method will be invoked by the Observable instance. This is analogous to using the hasNext() method in order to see if the traversal over the Iterable instance has finished and printing "We've finished!".

Note

This example is available at GitHub and can be viewed/downloaded at https://github.com/meddle0x53/learning-rxjava/blob/master/src/main/java/com/packtpub/reactive/chapter01/ObservableVSIterator.java.

We saw how we can use the Observable instances and that they are not so different from something familiar to us—the Iterator instance. These Observable instances can be used for building asynchronous streams and pushing data updates to their subscribers (they can have multiple subscribers).This is an implementation of the reactive programming paradigm. The data is being propagated to all the interested parties—the subscribers.

Coding using such streams is a more functional-like implementation of Reactive Programming. Of course, there are formal definitions and complex terms for it, but this is the simplest explanation.

Subscribing to events should be familiar; for example, clicking on a button in a GUI application fires an event which is propagated to the subscribers—handlers. But, using RxJava, we can create data streams from anything—file input, sockets, responses, variables, caches, user inputs, and so on. On top of that, consumers can be notified that the stream is closed, or that there has been an error. So, by using these streams, our applications can react to failure.

To summarize, a stream is a sequence of ongoing messages/events, ordered as they are processed in real time. It can be looked at as a value that is changing through time, and these changes can be observed by subscribers (consumers), dependent on it. So, going back to the example from Excel, we have effectively replaced the traditional variables with "reactive variables" or RxJava's Observable instances.

Implementing the reactive sum

Now that we are familiar with the Observable class and the idea of how to use it to code in a reactive way, we are ready to implement the reactive sum, mentioned at the beginning of this chapter.

Let's look at the requirements our program must fulfill:

It will be an application that runs in the terminal.
Once started, it will run until the user enters exit.
If the user enters a:<number>, the a collector will be updated to the <number>.
If the user enters b:<number>, the b collector will be updated to the <number>.
If the user enters anything else, it will be skipped.
When both the a and b collectors have initial values, their sum will automatically be computed and printed on the standard output in the format a + b = <sum>. On every change in a or b, the sum will be updated and printed.

The source code contains features that we will discuss in detail in the next four chapters.

The first piece of code represents the main body of the program:

ConnectableObservable<String> input = from(System.in); // (1)

Observable<Double> a = varStream("a", input); (2)
Observable<Double> b = varStream("b", input);

ReactiveSum sum = new ReactiveSum(a, b); (3)

input.connect(); (4)

There are a lot of new things happening here:

The first thing we must do is to create an Observable instance, representing the standard input stream (System.in). So, we use the from(InputStream) method (implementation will be presented in the next code snippet) to create a ConnectableObservable variable from the System.in. The ConnectableObservable variable is an Observable instance and starts emitting events coming from its source only after its connect() method is called. Read more on it in Chapter 3, Creating and Connecting Observables, Observers, and Subjects.
We create two Observable instances representing the a and b values, using the varStream(String, Observable) method, which we are going to examine later. The source stream for these values is the input stream.
We create a ReactiveSum instance, dependent on the a and b values.
And now, we can start listening to the input stream.

This code is responsible for building dependencies in the program and starting it off. The a and b values are dependent on the user input and their sum is dependent on them.

Now let's look at the implementation of the from(InputStream) method, which creates an Observable instance with the java.io.InputStream source:

static ConnectableObservable<String> from(final InputStream stream) {
  return from(new BufferedReader(new InputStreamReader(stream)));// (1)
}

static ConnectableObservable<String> from(final BufferedReader reader) {
  return Observable.create(new OnSubscribe<String>() { // (2)
    @Override
    public void call(Subscriber<? super String> subscriber) {
      if (subscriber.isUnsubscribed()) {  // (3)
        return;
      }
      try {
        String line;
        while(!subscriber.isUnsubscribed() &&
          (line = reader.readLine()) != null) { // (4)
            if (line == null || line.equals("exit")) { // (5)
              break;
            }
            subscriber.onNext(line); // (6)
          }
        }
        catch (IOException e) { // (7)
          subscriber.onError(e);
        }
        if (!subscriber.isUnsubscribed()) // (8)
        subscriber.onCompleted();
      }
    }
  }).publish(); // (9)
}

This is one complex piece of code, so let's look at it step-by-step:

This method implementation converts its InputStream parameter to the BufferedReader object and to calls the from(BufferedReader) method. We are doing that because we are going to use strings as data, and working with the Reader instance is easier.
So the actual implementation is in the second method. It returns an Observable instance, created using the Observable.create(OnSubscribe) method. This method is the one we are going to use the most in this book. It is used to create Observable instances with custom behavior. The rx.Observable.OnSubscribe interface passed to it has one method, call(Subscriber). This method is used to implement the behavior of the Observable instance because the Subscriber instance passed to it can be used to emit messages to the Observable instance's subscriber. A subscriber is the client of an Observable instance, which consumes its notifications. Read more about that in Chapter 3, Creating and Connecting Observables, Observers, and Subjects.
If the subscriber has already unsubscribed from this Observable instance, nothing should be done.
The main logic is to listen for user input, while the subscriber is subscribed. Every line the user enters in the terminal is treated as a message. This is the main loop of the program.
If the user enters the word exit and hits Enter, the main loop stops.
Otherwise, the message the user entered is passed as a notification to the subscriber of the Observable instance, using the onNext(T) method. This way, we pass everything to the interested parties. It's their job to filter out and transform the raw messages.
If there is an IO error, the subscribers are notified with an OnError notification through the onError(Throwable) method.
If the program reaches here (through breaking out of the main loop) and the subscriber is still subscribed to the Observable instance, an OnCompleted notification is sent to the subscribers using the onCompleted() method.
With the publish() method, we turn the new Observable instance into ConnectableObservable instance. We have to do this because, otherwise, for every subscription to this Observable instance, our logic will be executed from the beginning. In our case, we want to execute it only once and all the subscribers to receive the same notifications; this is achievable with the use of a ConnectableObservable instance. Read more about that in Chapter 3, Creating and Connecting Observables, Observers, and Subjects.

This illustrates a simplified way to turn Java's IO streams into Observable instances. Of course, with this main loop, the main thread of the program will block waiting for user input. This can be prevented using the right Scheduler instances to move the logic to another thread. We'll revisit this topic in Chapter 6, Using Concurrency and Parallelism with Schedulers.

Now, every line the user types into the terminal is propagated as a notification by the ConnectableObservable instance created by this method. The time has come to look at how we connect our value Observable instances, representing the collectors of the sum, to this input Observable instance. Here is the implementation of the varStream(String, Observable) method, which takes a name of a value and source Observable instance and returns an Observable instance representing this value:

public static Observable<Double> varStream(final String varName, Observable<String> input) {
  final Pattern pattern = Pattern.compile("\\^s*" + varName + "\\s*[:|=]\\s*(-?\\d+\\.?\\d*)$"); // (1)
  return input
  .map(new Func1<String, Matcher>() {
    public Matcher call(String str) {
      return pattern.matcher(str); // (2)
    }
  })
  .filter(new Func1<Matcher, Boolean>() {
    public Boolean call(Matcher matcher) {
      return matcher.matches() && matcher.group(1) != null; // (3)
    }
  })
  .map(new Func1<Matcher, Double>() {
    public Double call(Matcher matcher) {
      return Double.parseDouble(matcher.group(1)); // (4)
    }
  });
}

The map() and filter() methods called on the Observable instance here are part of the fluent API provided by RxJava. They can be called on an Observable instance, creating a new Observable instance that depends on these methods and that transforms or filters the incoming data. Using these methods the right way, you can express complex logic in a series of steps leading to your objective. Read more about this in Chapter 4, Transforming, Filtering, and Accumulating Your Data. Let's analyze the code:

Our variables are interested only in messages in the format <var_name>: <value> or <var_name> = <value>, so we are going to use this regular expression to filter and process only these kinds of messages. Remember that our input Observable instance sends each line the user writes; it is our job to handle it the right way.
Using the messages we receive from the input, we create a Matcher instance using the preceding regular expression as a pattern.
We pass through only data that matches the regular expression. Everything else is discarded.
Here, the value to set is extracted as a Double number value.

This is how the values a and b are represented by streams of double values, changing in time. Now we can implement their sum. We implemented it as a class that implements the Observer interface, because I wanted to show you another way of subscribing to Observable instances—using the Observer interface. Here is the code:

public static final class ReactiveSum implements Observer<Double> { // (1)
  private double sum;
  public ReactiveSum(Observable<Double> a, Observable<Double> b) {
    this.sum = 0;
    Observable.combineLatest(a, b, new Func2<Double, Double, Double>() { // (5)
      public Double call(Double a, Double b) {
        return a + b;
      }
    }).subscribe(this); // (6)
  }
  public void onCompleted() {
    System.out.println("Exiting last sum was : " + this.sum); // (4)
  }
  public void onError(Throwable e) {
    System.err.println("Got an error!"); // (3)
    e.printStackTrace();
  }
  public void onNext(Double sum) {
    this.sum = sum;
    System.out.println("update : a + b = " + sum); // (2)
  }
}

This is the implementation of the actual sum, dependent on the two Observable instances representing its collectors:

It is an Observer interface. The Observer instance can be passed to the Observable instance's subscribe(Observer) method and defines three methods that are named after the three types of notification: onNext(T), onError(Throwable), and onCompleted. Read more about this interface in Chapter 3, Creating and Connecting Observables, Observers, and Subjects.
In our onNext(Double) method implementation, we set the sum to the incoming value and print an update to the standard output.
If we get an error, we just print it.
When everything is done, we greet the user with the final sum.
We implement the sum with the combineLatest(Observable, Observable, Func2) method. This method creates a new Observable instance. The new Observable instance is updated when any of the two Observable instances, passed to combineLatest receives an update. The value emitted through the new Observable instance is computed by the third parameter—a function that has access to the latest values of the two source sequences. In our case, we sum up the values. There will be no notification until both of the Observable instances passed to the method emit at least one value. So, we will have the sum only when both a and b have notifications. Read more about this method and other combiners in Chapter 5, Combinators, Conditionals, and Error Handling.
We subscribe our Observer instance to the combined Observable instance.

Here is sample of what the output of this example would look like:

Reacitve Sum. Type 'a: <number>' and 'b: <number>' to try it.
a:4
b:5
update : a + b = 9.0
a:6
update : a + b = 11.0

So this is it! We have implemented our reactive sum using streams of data.

Note

The source code of this example can be downloaded and tried out from here: https://github.com/meddle0x53/learning-rxjava/blob/master/src/main/java/com/packtpub/reactive/chapter01/ReactiveSumV1.java.

T. Nield Jul 31, 2015

Pretty thorough book on RxJava, and even includes content on custom Operators and Transformers. the chapter on Schedulers was very well-explained and makes it clear how subscribeOn() and observeOn() behave. Although I had to re-read several parts of it, this book has helped me understand RxJava better than any other resource I have come across.I highly recommend downloading the source code to follow along rather than reading the code on paper.

Amazon Verified review

Amazon Customer Mar 29, 2016

Good

Dimitri K Feb 18, 2016

It is a nice book, thoughtfully written and with many details. One problem is that some complicated issues are explained too shortly, with few words and unclear diagrams, from which it is hard to understand the point. As if the author was in a hurry. I hope second edition will be improved.

Marty Jul 28, 2017

READ THIS BEFORE BUYINGThis book is very well written, but it is very much out of date. RxJava 2 is very different from RxJava1 which is what this book is based on. If you import the latest version of RxJava, the very first code sample in this book doesn't even compile. I'm bummed because I spent over $20 on this ebook and I can't even use it. You're better off looking at online docs or wait for this author to write a new book.

Bram Aug 02, 2016

One can only assume that this book was reviewed by hamsters who were taught English as a second language. No native speaker so much as breathed in the direction of this book while it was being edited, and it shows.

Learning Reactive Programming With Java 8: Learn how to use RxJava and its reactive Observables to build fast, concurrent, and powerful applications through detailed examples

What do you get with Print?

Learning Reactive Programming With Java 8

Chapter 1. An Introduction to Reactive Programming

What is reactive programming?

Tip

Why should we be reactive?

Introducing RxJava

Downloading and setting up RxJava

Note

Comparing the iterator pattern and the RxJava Observable

Note

Implementing the reactive sum

Note

Summary

Page 1 of 5

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs

Learning Reactive Programming With Java 8: Learn how to use RxJava and its reactive Observables to build fast, concurrent, and powerful applications through detailed examples

What do you get with Print?

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs