Experiment: Running Camunda on GraalVM Native Image

Camunda 7 Topics Discussion & Questions
1

Hi,

after I wrote a blog post about running Camunda in Quarkus in Febuary, I was asked on Twitter if I thought that Camunda could run on GraalVM Native Image. First I tried to dodge the Question on to Bernd Rücker, but he was not sure about it, either. This prompted me to try and make this work over the weekend. Quick summary: It didn’t. I published a summary of the process here: Running Camunda on GraalVM Native Image - Tim Zöller

I don’t think this is impossible, but the two main points I was not able to solve were Camundas usage of OSGI and Scala. I don’t have any experience in these topics and I don’t intend to learn them, maybe somebody here is more experienced with them and can give some pointers in the right direction? Are you interested in making this work, would you benefit from it?

Personally, I don’t think that running Camunda on Native Image is worth it. The big benefits of native image are fast startup time and a small memory footprint, but the main share of a process applications startup time is the initialization of the Process Engine itself. Also, natively compiled Java Application can’t make use of Javas JIT optimizations, so I would prefer my process applications on the JVM, still. What do you think?

Regards
Tim

5 Likes
2

Exciting work - thanks for taking the time to experiment and do such a great writeup! This will be an awesome starting point… Especially with having the sources available (https://github.com/javahippie/camunda-native-image) :+1:

1 Like
3

Just confirming on a related front, Tim. We’ve also been unable to get the Zeebe DMN worker running on GraalVM and have switched to a Maven base image instead.

1 Like
4

Thank you for confirming this, Doug! What errors did you see, where they also related to the JUEL engine?

5

Hi, Tim.

We began using GraalVM based on some casual discussions we were following in Camunda’s GitHub which mentioned it. Nothing we were doing was using GraalVM’s native features.

The image we’re using now is a Maven image with the jdk11-openj9 jvm on it, which has its own set of optimizations that don’t require fooling around with Java native (we’re primarily a C# .NET Core shop). We’ve found that the Maven image is also a lot cleaner to use for building Docker images.

So no, nothing related to the FUEL engine. Just a better fit for us, I’d say.

1 Like
6