Suspend everything you know about Java (and programming in general) for a moment, and let's make some observations about our world. These may sound like obvious statements, but as developers, we can easily overlook them. Try to become aware of the fact that everything is in motion. Traffic, weather, people, conversations, financial transactions, and so on are constantly changing or moving through stages.
Technically, even something as stationary as a rock is in motion, as its spatial location changes constantly due to the earth's rotation and orbiting through space. When you consider the possibility that everything can be modeled as being in motion, you may find it a bit overwhelming as a developer.
Another observation to note is that these different events are happening concurrently. Multiple activities are happening at the same time. Sometimes, they act independently, but at other times, they can converge and interact. For instance, a car can drive with no impact on a person jogging. They are two separate streams of events. However, they may converge at some point and the car will stop when it encounters the jogger.
If this is how our world works, why do we not model our code this way? Why do we not model code as multiple concurrent streams of events or data? It is not uncommon for developers to spend more time managing the states of objects and doing this in an imperative and sequential manner. You may structure your code to execute two independent processes, Process 1 and Process 2, and then Process 3, which depends on Process 1 and Process 2. Why not kick off Process 1 and Process 2 simultaneously, and then kick off Process 3 after the completion of these two processes? Of course, you can use callbacks and Java concurrency tools, but RxJava makes this much easier and safer to express.
Let's make one last observation. A book or music CD is static. A book is an unchanging sequence of words and a CD is a collection of tracks. There is nothing dynamic about them. However, when we read a book, we read one word at a time. Those words are effectively put in motion as a stream being consumed by our eyes. It is no different with a music track on a CD, where each track is put in motion as sound waves and your ears consume each track. Static items can, in fact, be put in motion too. This is an abstract but powerful idea because we create from each of these static items a series of events. When we level the playing field between data and events by treating them both the same, we unleash the power of functional programming and unlock abilities we previously might have thought impractical.
The fundamental idea behind reactive programming is that events are data and data are events. This may not seem intuitive, but it really does not take long to grasp when you consider our real-world examples. The runner and car both have properties and states, but they are also in motion. The book and CD are put in motion when they are consumed. Merging the event and data allows the code to feel organic and represent the world we are modeling.
