Thoughts on going reactive (was: [announce] InhiBeans: mitigate redundant recalculations)

Tomas Mikula tomas.mikula at
Tue Dec 17 12:55:04 PST 2013

I have a couple more thoughts on reactive programming in JavaFX:

1. Reactive programming is push-based (data/event driven). JavaFX
seems to be both push-based and pull-based. For example, event
handling and binding invalidation propagation are push-based, while
Binding.getValue() is pull-based. JavaFX uses this pull-based approach
for lazy evaluation of bindings. If we were going reactive, we would
need other techniques to avoid unnecessary computations, such as the
one discussed previously in this thread (i.e. InhiBeans). Well, lazy
bindings are not a silver bullet for all unnecessary computations

2. Reactive programming has to deal with concurrent systems and is
thus inherently asynchronous. JavaFX, on the other hand, is inherently
single-threaded and could use that as an asset. Reactive JavaFX should
get the best of both worlds, i.e. reactive and synchronous.
For example, the InhiBeans approach to avoid unnecessary computation, as in


relies on the fact that by the time area.release() is called, all the
changes from previous two lines have already been propagated to the
area property. There would be no such guarantee in an asynchronous
setting. I think such guarantees should be taken advantage of when
designing reactive JavaFX.

Sure, we could avoid unnecessary computation even in a fully
asynchronous fashion, but that would increase complexity, probably
employing something like Petri nets.


On Tue, Dec 17, 2013 at 8:24 AM, Tomas Mikula <tomas.mikula at> wrote:
> I had a quick look at Java 8 streams and I'm afraid they are of no use
> for reactive programming. The fundamental problem is that in
>, computation is driven by the stream consumer, rather
> than the stream source, which is a complete opposite of "reactive".
> On the other hand, JavaFX ObservableValue doubles as a poor man's
> event stream, but it would be confusing to use it as such. Not to
> mention that we still want map, filter, etc... on an event stream.
> Regards,
> Tomas
> On Mon, Dec 16, 2013 at 8:34 PM, Richard Bair <richard.bair at> wrote:
>> I agree, that's more of what I was thinking.
>> On Dec 16, 2013, at 10:31 AM, John Smith <John_Smith at> wrote:
>>> Perhaps reactive programming is different from the problem Tomas is solving, but I think a research project which combined some of the principles of functional reactive programming ( with JavaFX properties using Java 8 lambdas and streams would be quite interesting and perhaps very useful.
>>> John
>>> -----Original Message-----
>>> From: openjfx-dev-bounces at [mailto:openjfx-dev-bounces at] On Behalf Of Tomas Mikula
>>> Sent: Monday, December 16, 2013 9:19 AM
>>> To: Richard Bair
>>> Cc: openjfx-dev at
>>> Subject: Re: [announce] InhiBeans: mitigate redundant recalculations
>>> As a matter of fact, I have. Only to the extent of the "Principles of Reactive Programming" [1] course that is currently in progress on Coursera. >From what I have seen so far, it's all about asynchronous composition (with emphasis on both "asynchronous" and "composition").
>>> I didn't see it addressing this specific problem of multiple redundant updates, but I might be wrong. The truth is, this problem doesn't even exist if you don't have any eager observers (i.e. when you don't ever attach any ChangeListeners, and InvalidationListeners only propagate invalidation and never require the value to be recomputed). The problem is, although you can design your component without any eager evaluation (JavaFX bindings are already composed this way), you then bind a Label.textProperty() to the end of a binding chain and it all becomes eager.
>>> Regards,
>>> Tomas
>>> [1]
>>> On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair <richard.bair at> wrote:
>>>> Have you looked at by chance? I've been dying to see somebody do an RxJava in JavaFX ever since devoxx and it looks like you may have inadvertently started down that path :-).
>>>> Richard
>>>> On Dec 16, 2013, at 8:09 AM, Tomas Mikula <tomas.mikula at> wrote:
>>>>> On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula <tomas.mikula at> wrote:
>>>>>> On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer <swpalmer at> wrote:
>>>>>>> Interesting, no worse than John's pattern though.
>>>>>>> I thought of using a try/finally to make sure release was called
>>>>>>> and that naturally lead to thinking of try-with-resources, where
>>>>>>> the "resource" in this case is a binding of some sort (or a wrapper
>>>>>>> around a binding) that is invalidated on close() if needed.
>>>>>> That is an interesting idea. I didn't intend blockWhile() to be safe
>>>>>> with respect to exceptions, but merely
>>>>>> void blockWhile(Runnable r) {
>>>>>>   block();
>>>>>>   release();
>>>>>> }
>>>>>> Enhancement you are suggesting could be fleshed out as block()
>>>>>> returning an AutoCloseable and the usage would be
>>>>>> try(AutoCloseable a = relaxedArea.block()) {
>>>>>>   obj.setWidth(w);
>>>>>>   obj.setHeight(h);
>>>>>> }
>>>>> OK, done. I implemented both:
>>>>> 1. added the blockWhile() method;
>>>>> 2. made bindings AutoCloseable, and block() returns `this`.
>>>>> Tomas

More information about the openjfx-dev mailing list