Spring I/O 2019: a Trifork report

In 2010 I spoke at a new conference that Sergi Almar was organizing in Madrid about Spring. At that time it was mostly focused on Spanish attendees, and quite small.

Over the years the conference grew larger and larger, moved to Barcelona and became the biggest community-driven Spring conference in Europe, and probably the world, with over 1100 attendees this year!
Last year I spoke there for the second time, and enjoyed it so much that I really wanted to be there again for this year.

After submitting a proposal, two colleagues did the same and that proposal ended up becoming a workshop on combining reactive programming with CQRS and Event Sourcing using the Axon framework. As both were accepted, the three of us headed to Barcelona last week!

In this blog I will provide a short impression of the most important things that were covered at the conference.

Reactive all the things!

The main theme of the conference this year was reactive. Last year this was a major topic already as well, but this year the keynote covered reactive, there were many dedicated talks on reactive and even the other talks often featured some coverage.
New developments around the Spring reactive support that were covered were transaction support (actually announced during the conference), the development of the R2DBC spec plus implementations for reactive relational DB access and RSocket for reactive networking with back pressure support. The keynote covered some of these topics already, and Ben Hale’s presentation on RSocket was voted best of the conference.

We got the impression that more developers were actually using some of the Spring 5 reactive features like WebFlux and the WebClient in their own code already than we would’ve thought, especially in the workshop that my colleagues Erwin de Gier and Charlotte Hibert gave. Apparently most people are at least experimenting with the reactive support already, although I’d say that the lack of support for things like transactions and relational databases as well as proper debug tooling so far have prevented it from becoming mainstream and a real replacement for the traditional request-per-thread model. Given all the recent developments and improvements, this might change in the not-so-distant future though.

There will be a 0.8 release of R2DBC which will be production-ready from a quality point-of-view, but which may still receive some breaking changes before becoming 1.0. It was made clear that R2DBC itself is not directly intended for consumption by developers, but that it’s the foundation for higher-level abstractions like Spring Data repositories. This will avoid the mistakes made with JDBC, which is on the one hand too high-level to be easy to implement by vendors, but on the other hand too low-level and cumbersome to program against directly. Several databases will be supported, included H2, MS SQL Server, MySQL and PostgreSQL.

With Kotlin coroutines now being production-ready, they provide an interesting alternative to using the Reactor types directly: Spring supports the “suspended fun” construct which enables a more imperative programming style that still benefits from a non-blocking runtime, which I personally find very promising. As Trifork is already using Kotlin in several projects, this is definitely something that we will investigate.

Another big improvement to make reactive programming more feasible is two helper projects for finding blocking code (BlockHound) and an agent-based debug helper which will produce stack traces that actually contain some useful info, rather than just tons of Reactor internals.
I like the focus on making this programming model more user-friendly, as I consider the development experience with reactive so far sub-par, not outweighing the benefits for most applications.

Gradle dependency management

Since I’m using the Spring Boot Gradle support in my current multi-module project I attended a talk by Andy Wilkinson from Pivotal and Jenn Strater from Gradle. Andy wrote the dependency management plugin that’s typically used alongside the Boot Gradle plugin and provides support for managed dependencies in Gradle, including using Bill-Of-Materials POMs, typically called BOMs. This makes it easy to manage dependencies centrally, enforce versions and essentially make it more Maven-like — which in this case can be considered a good thing, and apparently a lot of people agree with that as it’s one of the most popular plugins for Gradle.

However, Gradle has added its own dependency management features in recent versions, including native BOM support. Even though there are some subtle and sometimes not-so-subtle differences (e.g. downgrading a managed version is still really hard in Gradle itself), for most typical use cases migration shouldn’t cause too much trouble yet will leave you with a faster build because the built-in support can be much more efficient than what the plugin can achieve through Gradle’s public APIs.
I learned about Gradle’s “–scan” option, which provides an interactive report of your build which you can use to trace where your build time is being spent: something I’m definitely going to spend some time with.

The plugin will still be supported for the foreseeable future, but the recommendation is to switch to Gradle’s native dependency management support if you can; that’s one more item on our backlog now.

Core Spring updates

Juergen Hoeller talked about what’s being developed for Spring 5.2 and what’s planned for 5.3. As expected things like tracking new versions of Java came along, although Java 8 will remain the baseline version. There’s a lot of work being done in collaboration with Oracle to make Spring play nice with GraalVM: for example, this means that @Configuration classes can’t use CGLib anymore to ensure singleton behavior for explicit calls to @Bean methods, which might mean some (straightforward) rewriting of your configuration code to comply.
Even without GraalVM you will benefit from faster startup times, as a lot of work has gone into analysis and subsequent improvements in that area.

The functional style of registering controllers is now available for Spring-MVC as well, there’s improvements for handling application events in a non-blocking fashion, and there were many other things that I don’t remember right now (I didn’t take notes).

Interestingly enough, there were some explicit non-goals for 5.3 as well: for example, while Java Fibers sounds like an amazing alternative to write efficient concurrent code, it’s too far away to take into account already. The same goes for supporting Jakarta EE, following the outcome of the discussions with the Eclipse foundation that they won’t be allowed to add anything to the javax.* packages.

Moving on from Spring Cloud Netflix

As Netflix stopped supporting Ribbon and Zuul 1 quite some time ago already and recently stopped supporting Hystrix as well, the Spring Cloud team is working on offering some alternatives. For Zuul that existed already in the form of Spring Cloud Gateway; for Ribbon and Hystrix new options are being developed (Spring Cloud Loadbalancer and Spring Cloud Circuit Breaker). Marcin Grzejszcak and Olga Maciaszek-Sharma provided an overview of what migrating from the old to the new stack might entail, based on a sample set of services.
We’re using all of these Netflix services on my current project, with Zuul being used embedded within regular Spring-MVC-based services on the side. Moving to Spring Cloud Gateway would mean moving to a reactive stack for us, but if you have a more typical use of Zuul as a separate API gateway then for many straightforward use-cases you don’t really have to worry much about that as you’re mostly just rewriting configuration.

The new circuit breaking support will integrate with various solutions, including the recommended Resilience4J. It’s not clear yet if Spring Cloud Circuit Breaker will also support an annotation-based programming model: right now the approach is based on lambdas, which is actually a nice programming model but would mean more work to migrate away from the Javanica @HystrixCommand based approach that I believe most Hystrix users will currently use in their projects.

Trifork Sessions

On Thursday my colleagues Charlotte Hibert and Erwin de Gier hosted a workshop on reactive programming in the context of a CQRS/event-sourced application using Axon.
Based on trial runs the expectation was that most attendees would be completely new to reactive programming but might have some understanding of CQRS and event-sourcing already, but in practice this tended to be the other way around: as a result all attendees managed to do the various exercises without a lot of trouble, making the workshop a great success.

For the people that wanted to hear more about the Axon parts, Allard Buijze from AxonIQ gave a talk on Friday on how Axon with its support for location transparency and distribution via the Axon Server makes decomposing your applications into distributed systems “excitingly boring”.

That same Friday I delivered my “Boot Loot” talk, in which I provided various tips & tricks for working with Spring Boot based on my experience in various projects running in production. I crammed as much as I could into 50 minutes, so when the YouTube video comes online you probably won’t need to speed it up 😉

Additional information added:
Joris Kuipers Presentation “Boot Loot – up your game and Spring like the pros” on Spring I/O:
Video: https://youtu.be/azTAKKCtNXE
Slides: https://www.slideshare.net/jkuipers/boot-loot …
GitHub repo: https://github.com/jkuipers/bootloot

What else?

Of course, conferences are more than just a series of talks: it’s about meeting old and new friends, food and drinks, and being away from your keyboard long enough to have the chance for some reflection on how what you’re hearing about relates to what you are doing in your projects. Charlotte and I tremendously enjoyed the speakers dinner: there was a new location this year, where we were treated to various tapas and live-cut charcuterie:

I met up with a lot of the old SpringSource crew as well as ex-Triforker Tim van Baarsen and his ING colleague and the Faros gang, who deliver the Core Spring course (that we host in The Netherland) in Belgium.

On Thursday I was invited to join several Pivotal people for a Japanese dinner, which provided great food ánd company: thanks again, guys!
On top of that, ex-Triforker David Caron who now works for Pivotal as a Platform Architect arranged some long sought-after Spring T-shirts for me to wear when delivering the Core Spring training: thanks for liberating them out of custom’s captivity and bringing them to Barcelona, David!

To close off, even though there were many people making this conference the success that it was, I really want to thank Sergi Almar for putting up such a great show again this year: hopefully we’ll be back next year!