Reactor 2.5 : A Second Generation Reactive Foundation for the JVM Skip to main content Learn more about Day 0 access to security patches via Enterprise support. Why Spring Overview Trending Generative AI Cloud Architecture Patterns Microservices Reactive Event Driven Application Types Web Applications Serverless Batch Learn Getting Started Quickstart Guides Academy Courses Get Certified Projects Overview Projects Spring Boot Spring Framework Spring Cloud Spring AI Spring Data Spring Integration Spring Batch Spring Security Foundational Projects Micrometer Reactor Development Tools Spring Tools Spring Initializr Resources Blog Release Calendar Version Mappings Release Highlights Security Advisories GitHub Orgs Spring Projects Spring Cloud Community Overview Events Authors Enterprise Overview Long-term Support Automated Upgrades Governance and Compliance Modern App Development Spring Blog RSS feeds All Posts Engineering Releases News & Events Reactor 2.5 : A Second Generation Reactive Foundation for the JVM Releases | Stephane Maldini | February 16, 2016 | 4 min read | ... Entering Reactive Streams Era Reactor 2.0 development started by the end of 2014, around the same time as Reactive Streams. We were keen on joining the effort and early adopt a backpressure protocol to mitigate our main message-passing limitation: bounded capacity. We delivered in Reactor 2.0 the first attempt to make Reactive Streams implementations of RingBuffer-based schedulers and derived an increasingly popular reactive pattern: Reactive Extensions. Meanwhile, Reactive Streams started getting traction and an entire ecosystem of libraries discussed this transition. The regular concern ? Implementing Reactive Streams semantics is all but an easy task. We observed an increasing need for a reactive foundation to solve message-passing and implement common streaming operators. We therefore created a dedicated project space for Reactor Core and started a focused effort with Spring Framework team. Starting from 2.5, Reactor is now organized into multiple projects, maintenance branches such as 2.0.x are left unaltered. This is reflected in release management, for instance Reactor Core 2.5 M1 is the only milestone available and other projects will follow with their exclusive versioning. To support this new project model, we deployed a new and hopefully more welcoming site on http://projectreactor.io. A collaborative new take on Reactive Streams This new organization unlocked a far cheaper ticket price to get involved with the project activities. The project benefits from Spring API design collaboration and direct contributions notably from Sébastien Deleuze and Brian Clozel. Reactor also welcomes the help of new external contributors and reviewers : Alex Petrov re-inventing the popular Reactor event routing features. Anatoly Kadyshev who works on the amazingly efficient Aeron Reactive Streams bridge for Reactor IO. Ben Hale and his team working on the new Reactive Cloud Foundry Client API. More than early adopting Reactor 2.5 Core and Stream, Ben keeps iterating with us on his real-world use cases. Damien Vitrac contributing the new project site style and preparing the Reactor Console user experience. Dávid Karnok, researcher, main active RxJava committer and author of the excellent Advanced RxJava blog, strongly influenced our internal operational model. Our shared passion for efficiency and reactive patterns led us to create a research space, Reactive Streams Commons. Dependencies and Collaborations at play with Reactor 2.5 Reactive Streams Commons The Reactive Streams Commons repository is an open research effort focusing on efficiency with Reactive Extensions and more, for the Reactive Streams specification. It is fully inlined by Reactor Core and Stream which operate as contract gates for the many revolutions the effort focuses on. "RSC" is therefore a freeform project similar to the JCTools take on concurrent queues. One of its biggest progress is a form of "Fusion" protocol to reduce overhead of most synchronous and some asynchronous stages in a reactive processing chain. Finally, the effort helped fixing more than a hundred of streaming bugs and our testing process now involves RSC unit/integration testing and JMH benchmarks combined with Reactor own integration testing and benchmarks. Reactor Core 2.5.0.M1 Today's Reactor blog series starts with a joyful event, Reactor Core 2.5.0.M1 release ! Under its new scope and close ties with Reactive Streams Commons, Reactor Core offers just enough Rx coverage to build reactive apps or libraries alike , e.g. Spring Reactive Web support. For the impatient reader, have a look at the already available quickstart on github. A quick glance at a scatter-gather scenario: Mono.from(userRequestPublisher) .then(userRepository::findUserProfile, userRepository::findUserPaymentMethod) .log("user.requests") .or(Mono.delay(5) .then(n - Mono.error(new TimeoutException())) .mergeWith(userRepository::findSimilarUserDetails) .map(userDetailsTuple - userDetailsTuple.t1.username) .publishOn(SchedulerGroup.io()) .subscribe(responseSubscriber); In details : Flux, a Publisher of 0 to N data signals with a lite Rx scope. Operators include create(), interval(), merge(), zip(), concat(), switchOnError() and switchOnEmpty() Mono, a Publisher of 0 or 1 data signal with a lite Rx derived scope adapted to strongly type this specific volume nature. Operators include delay(), then(), any(), and(), or(), otherwise(), otherwiseIfEmpty(), where() and a blocking get(). New simple scheduling contract based on plain Java interfaces (Runnable, Callable). -- Featuring SchedulerGroup, TopicProcessor and WorkQueueProcessor. -- Superseed the former Enviroment/Dispatcher couple while answering the same needs and a simple migration path will shortly be documented. No more static state holding references of dispatchers. -- Linked operators : publishOn() and dispatchOn() Test support for Publisher sources with TestSubscriber. Convert Callable, Runnable, Iterable, Java 8 CompletableFuture, Java 9 Flow.Publisher, RxJava 1 Observable and Single to Reactive Streams ready Flux and Mono, no extra bridge dependency required. Fully revamped and integrated Javadoc, including slightly adjusted marble diagrams. A micro toolkit of utils and base Subscriber to reuse at will to implement your own Reactive components. -- A cost-efficient Timer API and implementation (hash-wheel timer). -- New Fusion API to virtually conflate 2 or more stages from a reactive chain -- An adapted QueueSupplier that will provide the right queue for the right capacity New Introspection API based on state and flow representations. -- Publisher Logging with fallback to java.util.logging or SLF4J if available. Can directly be used on Flux and Mono with log() operator. -- Orthogonal to any other contract including Reactive Streams, everything can be Backpressurable , a Completable or be a Receiver producing to a generic Object (possibly a Subscriber), which in return allows us to trace down the full graph of a flow and augment it with state indicators: What's (on)Next ? We'd like to collect your very feedback, you can assault the respective issues repository or join our recently created Gitter channel. Stay tuned for the next entry about Reactor Stream 2.5.0.M1, the complete Rx over Reactive Streams implementation. Get the Spring newsletter Stay connected with the Spring newsletter Subscribe Get ahead VMware offers training and certification to turbo-charge your progress.Learn moreGet support Tanzu Spring offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.Learn moreUpcoming events Check out all the upcoming events in the Spring community.View all Why Spring Generative AI Microservices Reactive Event Driven Cloud Web Applications Serverless Batch Learn Quickstart Guides Courses Get Certified Projects Resources Blog Release Calendar Version Mappings Release Highlights Security Advisories Community Events Authors Enterprise Long-term Support Automated Upgrades Governance and Compliance Modern App Development Thank You Copyright © 2005 - 2026 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. Terms of Use • Privacy • Trademark Guidelines Apache®, Apache Tomcat®, Apache Kafka®, Apache Cassandra™, and Apache Geode™ are trademarks or registered trademarks of the Apache Software Foundation in the United States and/or other countries. Java™, Java™ SE, Java™ EE, and OpenJDK™ are trademarks of Oracle and/or its affiliates. Kubernetes® is a registered trademark of the Linux Foundation in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Windows® and Microsoft® Azure are registered trademarks of Microsoft Corporation. “AWS” and “Amazon Web Services” are trademarks or registered trademarks of Amazon.com Inc. or its affiliates. All other trademarks and copyrights are property of their respective owners and are only mentioned for informative purposes. Other names may be trademarks of their respective owners.