The rise of distributed programming and the ubiquity of multi-core processors have renewed interest in reactive programming. It is this reality that led the Spring team to invest in making reactive programming more accessible. Of course, most projects will continue to use traditional imperative / blocking style development. In Spring Framework 5, we’re offering the community the freedom to choose the right stack for the right job.
Choosing between reactive programming vs. traditional blocking style or imperative development is a nuanced decision. Both have their place, but understanding when, where, why and “for what goal” is essential to achieving a positive result. Otherwise it can be frustrating, even downright dangerous. With the advent of Spring Framework 5, the choice is yours. As the good Dr. David Syer and Rossen Stoyanchev instruct us, use it wisely.
Major version Spring Framework releases don’t happen everyday and this 5th generation is the most significant since the project’s inception in 2004. It introduces an alternative programming paradigm that will be supported by the entire project ecosystem:
- A Reactive web framework via Spring WebFlux in annotated or functional styles. Spring WebFlux is built on Project Reactor 3.1. It supports RxJava 1.3 & 2.1, and it runs on Tomcat, Jetty, Netty, or Undertow. Use on your preferred reactive runtime with no code changes!
- Native Kotlin extensions. Code your cloud functions and microservices in a functional style with Java 8 & Kotlin! Version 5.0 ships with bean registration and functional web endpoints. And more extensions are coming for function and microservice developers!
- Developers can fully exploit modern Java with Spring Framework 5.0: Full alignment with JDK 9 at runtime, on the classpath, and the module path. Spring Framework 5 includes many exciting Java 8 and core DI container improvements as well.
- Integration with popular Java EE 8 APIs. The Framework supports Servlet 4.0 and Bean Validation 2.0, and JPA 2.2. It also works with, and the JSON Binding API, as an alternative to Jackson/Gson in Spring MVC. Spring Framework 5 works with the current releases of Tomcat, Jetty, and Wildfly.
- There are many further refinements across the Framework. Check out our updated what’s new page for a comprehensive overview of changes since 4.3, including support for the newly released JUnit 5.0 and Hibernate Validator 6.0 and the FAQ to learn more!
The Spring ecosystem is picking up reactive programming at an extremely aggressive pace, with reactive releases of Spring Security and Spring Data (plus many more) already available.
The State of Reactive Programming
Reactive programming isn’t a new thing. Microsoft’s reactive extensions, JVM options like Scala/Akka, RxJava, and Vert.x have been around for awhile. New vendors are getting involved. Companies like Kaazing, Netflix, Pivotal, Red Hat, Twitter, and Lightbend (Typesafe) collaborated around a specification called Reactive Streams. We collectively formed an agreement on low level reactive concepts that are now being used in JDK 9. Higher level frameworks like Akka, RxJava, Reactor, Ratpack and Spring Framework 5.0 are using these ideas too.
However, mainstream IT has survived without widespread usage of reactive programming for a long time. After 20 years of having a synchronous / blocking Servlet API, why now?
We see three main drivers:
Microservices are everywhere. The increasing adoption of highly distributed, event driven architectures often leads to applications exhibiting complex function / service interdependence and sequencing. As that increases, throughput can start to hit a ceiling with synchronous, blocking systems - causing overall system failure. The need to consume events (which map nicely to messages) with high concurrency then becomes very important in these scenarios: streaming or real time data, for example, often demands fast messaging ingestion. Spring is the dominant microservices framework, so investing in reactive programming becomes a natural next step.
Resource availability at the high end. Reactive applications aim for maximum service availability, achieved by decoupling network latency from request processing. It’s the only way a service can remain available when attempting to handle extreme request volumes.
Functions-as-a-service. Microservices are now the norm but recent efforts in resource mutualization, tooling and cloud computing raise a new question: Is the next frontier function-oriented? Function-as-a-Service, or “serverless”, pushes the data distribution even further, increasing network latency. Reactive systems become even more important here, and our latest progress with Spring Cloud Function fully embraces this style.
What’s different about Spring Framework 5?
Should everything be written as cloud function in the future? Should everything be written as a microservice? Of course not. Having a spectrum of options is the key: Spring Framework 5 stands out among today’s JVM-based options due to the flexibility and choice it enables. Go reactive (or don’t), use your favorite reactive runtime, enjoy different programming model options, support for RxJava and Reactor, and of course, the imminent Spring Boot support. Also, it’s similarity to the market-leading Spring MVC makes it unique. We believe developers will also appreciate having functional programming model (and even JVM language options) when authoring reactive cloud functions and microservices.
Use the Right Tools for the Job
In summary, make the reactive choice with care. Netflix, when working on Zuul 2, made similar observations, noting how the performance and the predictability of resource consumption helped them autoscale efficiently. It also made the system considerably more difficult to operate and debug. As the good Dr. David Syer tells us:
“For the right problem, the effects are dramatic. For the wrong problem, the effects might go into reverse (you actually make things worse). Also remember, even if you pick the right problem, there is no such thing as a free lunch, and Reactive doesn’t solve the problems for you, it just gives you a toolbox that you can use to implement solutions.”
About the Author
Pieter Humphrey is a Product Marketing Manager responsible for Java Developer Marketing at Pivotal Software, Inc. Pieter comes from BEA/Oracle with long history of developer tools, Java EE, SOA, EAI, application server and other Java middleware as both a marketing guy and sales engineer since 1998. Find me on Twitter at https://www.twitter.com/pieterhumphrey.More Content by Pieter Humphrey