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.
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:
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.
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:
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!
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?
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.
Principal Software Architect
A core developer at Flowable with over a decade of experience in open source software and of building scalable process engines. He co-founded the Activiti project (on which Flowable is based) and was part of the JBoss jBPM team before that.
Share this Blog post
Engineering | SEPTEMBER 7, 2022
Escape from Legacy
With common origins and some recent open source updates to Flowable’s engines, it is possible to migrate a Camunda 7 or Activiti 5/6 instance to Flowable in-place, including active processes and history.Read more
Engineering | JUNE 21, 2022
Visual debugging of BPMN and CMMN with Flowable Inspect
Visual debugging of BPMN and CMMN with Flowable Inspect One of the smartest and unique features of Flowable is the ability to debug and…Read more
Business | MARCH 24, 2022
Reacting when your UI framework reaches end of life
Our long-serving automation editing application, Flowable Design, was built using the AngularJS UI framework. Time to react. Well, to React.Read more