# Operator fusion (part 2 - final)

DevFeed: [Operator fusion (part 2 - final)](<https://devfeed.tech/articles/operator-fusion-part-2-final-24802.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2016/04/operator-fusion-part-2-final.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2016-04-19T14:57:00Z

Content type: article

Language: en

Sources: [Akarnokd - Advanced RxJava](<https://devfeed.tech/sources/akarnokd-advanced-rxjava.md>)

Topics: [reactive](<https://devfeed.tech/topics/reactive.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Streams](<https://devfeed.tech/topics/streams.md>), [Java](<https://devfeed.tech/topics/java.md>)

Tags: [java](<https://devfeed.tech/tags/java.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [reactive-streams](<https://devfeed.tech/tags/reactive-streams.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [streams](<https://devfeed.tech/tags/streams.md>)

## AI overview

This article explains the API and protocol mechanisms behind operator fusion in Reactive Streams. It focuses on macro-fusion for synchronous sources that emit zero or one element, including just(), empty(), and fromCallable(), and describes using Callable and ScalarCallable to enable optimization.

## Source excerpt

Introduction In the previous part, I've introduced the concepts around operator fusion. In this post, I'll detail the API and protocols required make operator fusion happen. In its current form, operator fusion works between two subsequent operators and is based on the ability to identify each other and, in case of micro-fusion, switch to a different protocol than Reactive-Streams (RS) if both agree. Macro-fusion constructs The primary targets of macro-fusion are the single element sources: just(), empty(), fromCallable(). Firing up the complete RS infrastructure for such single elements is quite expensive, but half of the API use in RxJava and Reactor come from these. Therefore, RxJava introduced Single and Reactor introduced Mono to help as much as possible and offer (ever increasingly) optimized operators on them. However, knowing a source will generate 0 or 1 element during assembly time is also a great help in regular Observable / Flux uses. In addition, knowing the source is also a constant helps inlining it in via some custom operator. Creating 0 or 1 element synchronous sources To indicate a source returns a single value, the Reactive-Streams-Commons (Rsc) project (and Reactor off it) established a contract: If a Publisher implements java.util.concurrent.Callable, it is considered a 0 or 1 element source. You can implement Callable and return a non-null value that can be computed synchronously. You can also return null which indicates an empty result. (Remember, RS doesn't allow null values over onNext.) The call to call() will happen during subscription time. public class MySingleSource implements Publisher<Object>, Callable<Object> { @Override public void subscribe(Subscriber<? super Object> s) { s.onSubscribe(new ScalarSubscription<>(s, System.currentTimeMillis())); } @Override public Object call() throws Exception { return System.currentTimeMillis(); } } If the 0 or 1 element source is known to be constant, the source can be the subject of assembly time