vJUG: Fully Reactive: Spring, Kotlin, and JavaFX Playing Together

Introduction

Recently, I watched a recorded vJUG session: Fully Reactive: Spring, Kotlin, and JavaFX Playing Together. Unfortunately, I was not able to tune in live to this one, but I am grateful that the vJUG team puts effort into recording every session. This presentation was given by Trisha Gee of JetBrains. I'm used to reading the JetBrains newsletter that she curates, "Java Annotated Monthly", so I was excited to see her present.

Aside: I highly recommend the newsletter for Java devs out there: subscribe on JetBrains website.

Coming into the session, I already knew a little about Spring, Kotlin, and reactive programming because I had some experience with the combination on a client project this past year. Learning Kotlin and Project Reactor at the same time was quite a lot, but I think they would be more digestible if taken one at a time. Now that I am on the other side, I can see the appeal, but I don't think that it is for every project. Trisha even said this towards the end: she likes Kotlin, but she's still much more comfortable starting a new project in Java because it's infinitely more familiar.

For the presentation, Trisha gave a live demo of setting up the following to demonstrate different aspects of reactive programming:

• Spring Boot Reactive HTTP API – serves a stream of stock prices for a given ticker symbol
• Reactive HTTP client – small client library to consume the API
• JavaFX + Spring Boot client application – renders price-over-time data for a given ticker symbol provided by the API

Spring Boot API

Setting up the API was the most familiar part of the presentation (and should be for most developers who have worked with Spring Boot). Trisha set up a Maven-based Spring Boot app pulling in the Reactive Web dependency and written in Kotlin. She then provided a RestController class with one GET mapping that spits out a stream of random prices.

The part of this that probably stands out is the stream and the use of Project Reactor's Flux class.

A Flux just represents 0:N values of a particular type. Like a collection, but reactive. By this I mean, you have to subscribe to the Flux object and consume it to get any data back. The API afforded by Project Reactor for what to do with Flux objects is extensive. Trisha touches on this during the presentation when she highlights a few handy methods for setting up retries and error handling.

In Trisha's demo, she describes the HTTP endpoint as returning an event stream media type. I am not familiar with this content type, so it's something I need to do more reading on. When demoing the API, Trisha opened the endpoint in a browser window and showed that every second, a new JSON object appeared with a price object. Later on, the JavaFX app dynamically consumes this and draws a chart based on the stream of data.

Reactive HTTP Client

For the client code consuming the new API, Trisha showed how to write a reactive consumer in Java. The project set up is still for a Spring Boot "app" even though the application runtime is not used. This comes in handy for managing dependencies and declaring Spring auto-configuration that can be used the JavaFX app later.

A cool part of this was showing how the API and the ergonomics of Reactor and Kotlin are similar and different. In the client app, Trisha also pulled in Lombok, so, as an example, she highlighted how, from a developer convenience point-of-view, there is not much different from a Kotlin data class and a POJO annotated with @Data from Lombok. However, the brevity that is enabled by Kotlin is significant. In my experience working with it, that conciseness does sometimes come at a readability cost. Again, your mileage may vary by team.

JavaFX App

To keep the demo simple, Trisha simply added a new module for the JavaFX app so that it could easily pull in the HTTP client. This was also written in Java and used Spring Boot.

I'm not familiar with JavaFX apart from knowing that it exists, so I was very curious about the framework and API. In this presentation, Trisha was not able to go into too much detail about JavaFX, but she did stand up a working Java client UI app pretty quickly. I'll again have to do some of my own reading and experimentation here. My primary take-away is that, especially with Spring Boot, you can wire up a UI client application with JavaFX with relative ease. The built-in chart tool seemed pretty capable from the brief demo.

Trisha emphasized here how to consume data from a Flux and that event-driven architectures work very well with the reactive paradigm. In particular, since data could come from the Flux at any time, being able to de-couple the UI updates from data changes via an event leads to pretty clean and maintainable code. Granted, this was a demo app, but I think the principle is valid. Event-driven patterns also seem to play well with both Spring and JavaFX, so it fit together comfortably once everything was wired together.

Conclusion

Whether or not they are appropriate for your project or your team, it feels like reactive programming is getting a lot of attention right now. Many projects are making it easy to get started and be productive with more advanced features of reactive architecture. It was cool to see Trisha demo this both with a form that a lot of us Java devs are familiar with – a Spring Boot API – as well as something likely more unfamiliar – a JavaFX application. Support for reactive models is growing and usage of Project Reactor APIs in the Spring ecosystem is arguably already stable. I recommend checking it out even if you don't pick it for your next production project. It's a constantly evolving area right now!

As always, if you have any questions or feedback, feel free to reach out on Twitter.