Previously

At Flowable, we've been fans of GraalVM since the very beginning. If you don't know what it is: GraalVM is one of the many implementations of the JDK (Java Development Kit) out there. But more importantly, it includes tools to build a 'native image', which is a binary version of your Java application that is optimised for high performance and low-memory usage. The image contains everything to run, so it can be copied to a server and run as-is without installing anything. The idea of having an optimised, as-small-as-possible native executable image for an application embedding the Flowable engines is obviously extremely enthralling.

Our Flowable Spring Boot starters are very popular and widely used. In fact, our commercial enterprise products are fully based on those starters and the architecture found in the open-source project. So when about a year ago Spring Native was announced, we jumped on the bandwagon immediately and published our results in a blog.

Getting Flowable - or any other framework for that matter - to work properly in a native image back in the day took a lot of effort, trial-and-error and many workarounds. But in the end, we managed to make it work, though we had to add a few workarounds and generate a lot of configuration files. The whole thing was not maintainable for the long run, but hey, it was the early days!

Spring Native 0.11

So you can imagine that seeing the announcement for Spring Native 0.11 back in December immediately got our interest. Not because a new version was released, but because it included a brand-new Ahead-of-Time (AOT) engine to determine which classes needed to be included in a native image. This AOT engine would infer automatically which classes are configured to a large extent, something we had to somewhat brute-force in our previous blog by generating the GraalVM configuration files in a hardcoded way.

Secondly, as clearly described in that announcement blog, Spring Native will be a focal point in the upcoming new major versions of Spring and Spring Boot. In Spring 6 and Spring Boot 3, native support will be a major theme. Keeping an eye on this is crucial for future developments.

Enter Josh

We were actually prototyping things around Flowable and Spring Native when we got a ping from Spring Developer Advocate and long-term Flowable enthusiast/committer Josh Long on this very subject.

Josh has been busy in the past few weeks at working on and writing about this very topic:

• Mybatis and Spring Native 0.11.x, which is very interesting to us as the persistence of Flowable is based on Mybatis.

• Spring Native, GraalVM, and Kubernetes Native Java, which honestly is a great read to get an in-depth read on everything around Spring Native, GraalVM and what is means for cloud deployments. If you read anything (besides this post, of course ;-)), it should be this link.

• Spring Native Extension Points, which documents how easy it has become to add GraalVM 'hints'. He publishes all hints he builds on his Github repo too.

The work from Josh around Christmas then triggered the Mybatis team to work on and officially publish Mybatis Spring Native support. Which was a perfect timing for us. Isn't open-source fantastic, folks :-)?

Spring Native support for Flowable

And in a similar vein, we did the natural open-source thing to do ... we got together for hacking a few hours on it:

The result of this can be found on our github repo.

Summarized:

• Using the new Spring Native hookpoints, we were able to create a FlowableProcessEngineNativeConfiguration that removes pretty much all of the hard-coded generated configuration files we used to need. Using reflection at build-time, we can now have GraalVM discover the Flowable classes without having to worry about maintenance in the future.

• This then gets picks up automatically by the Spring GraalVM build logic in Maven simply by adding our stuff to a spring.factories config file in the META-INF.

• With the above (and adding a few Hint classes from Josh), we can now define a Spring Boot application that boots up the engine against Postgresql (which has a driver that is GraalVM-ready). The application was generated by going to start.spring.io and adding 'native' as a dependency.

One of the tricky parts before was to make sure all relevant Flowable internal classes were discovered by the GraalVM compiler. For a dynamic platform such as Flowable, this is crucial as any new process or case can have arbitrary logic. Thankfully, all of this now works out of the box!

We can now build this application by executing

mvn -Pnative clean package -DskipTests

(you'll need GraalVM for this, we've used the latest 22.x release)

After a few minutes (depending on your computer's power) this now crafts a binary executable of the application. When running it, it shows that we boot up a full-blown Flowable + Spring Boot environment with a persistent database in half a second, without having to install anything. How awesome is that?

Going Forward

We're obviously thrilled by what's possible today, but more-so by what's coming.

Spring 6 and Spring Boot 3 will be a serious step up. Today, many Flowable users and customers are using technologies such as Docker and Kubernetes for some very cool use cases. In this context, having the option in the (near) future to create fast-booting, low-memory - even though Flowable always did very well in this area - automation application with processes, cases, rules and data is a clear win-win situation for everyone.