Beyond Java

But that's another days story. Today let's have a look at the bread-and-butter tasks. At its heart, GraalVM is a compiler running Java applications. And that's what the majority of readers need every day. So maybe this article is not that boring for you. Let's explore what GraalVM has in store for the average Java programmer.

State of the art

According to the official slides, videos, and conference talks, GraalVM is 100% production-ready. Cutting a long story short, we believe that's mostly true. The current version, 20.0, finally delivers Windows support. The JavaScript engine for Windows has finally landed. Both are great because the vast majority of programmers are using Windows, at least in Germany.

However, node.js support is still the domain of Linux and OSX. Node.js for Windows is scheduled to be shipped with version 20.1, which should arrive in a few months.

Talking about node.js: that's the one thing we were unhappy about. It's short of the marketing claims because the huge cold start penalty makes using tools like the Angular CLI a pain. But still, the CLI worked fine when we tried running it with GraalVM. It was just a bit slow.

But we don't think GraalVM is intended to make a significant impact on Web development. It's unlikely we're going to develop Angular, React.js, or Vue.js with GraalVM any time soon. In the short term, GraalVM is all about Java (and maybe Ruby and R). Polyglot programming is a topic of its own, but it's also part of the Java universe. GraalVM is a great successor of Rhino and Nashorn.

In the Java universe, there's little to complain. GraalVM gracefully coped with every Java application we threw at it. It didn't run the app much better or faster than OpenJDK, but it wasn't worse, either.

Our exhaustive long-term experience (or the lack of it)

At this point, we should tell you we're happy power-users of GraalVM. We should tell you we're using it every day, and since we adopted it, our productivity skyrocketed.

That's what we should do. The problem is, we can't. Like so many other corporate programmers, we're stuck with what our customer demands. GraalVM isn't top on their priority list. Actually, that's why we began writing this series in the first place: we believe that GraalVM is a game-changer in the Java world - and possibly even beyond it! - so we've decided to share our enthusiasm with you.

Image by Gerhard Gellinger on Pixabay

So what did we test?

We started small. We wrote a small application calculating the surface of a circle. That worked like a charm.

So we became brave-hearted and ran a little Spring Boot application. Feel free to run your own experiments. We've shared our demo application on a GitHub repository.

Spring Boot is a giant piece of software. Most developers may consider it light-weight, but that's a slightly outdated perception. Spring used to be small and cute, but during the last decade, it's grown beyond imagination.

Hence, our working theory is that if GraalVM manages to run Spring Boot, it'll swallow everything.

Well, GraalVM passed the test with flying colors. We were a bit underwhelmed by the performance. We saw a tiny 7% performance boost with GraalVM 19.3. We didn't have the opportunity to run it with the current 20.0 version. Chances are when you're reading this article, there's an even newer GraalVM, which might be a lot faster.

Be that as it may, our intermediate result is that GraalVM is faster than the standard JVM, but only by a margin. On the other hand, that's just great if you take into account that GraalVM is the new kid on the block.

Quarkus

There's that. But is it a good idea to use GraalVM with Spring Boot?

Quarkus is one of the new "microframeworks" written specifically with GraalVM in mind. We know the Spring Boot team is working on GraalVM support, and they've got virtually unlimited resources. So they might win the game. As for now, Quarkus is a much more exciting contender.

That shows clearly in our test results. Or maybe it doesn't. Quarkus was a lot faster than Spring Boot in our cold-start test. Don't take our word for it: we've shared the source code on GitHub, so you can run your own benchmarks.

The good news is that Quarkus starts more than twice as fast as Spring Boot. That's great if you're writing an Amazon Lambda service. Every second counts.

The bad news it that GraalVM 19.3 runs the Quarkus cold-start test merely five percent faster than the HotSpot compiler. That's such a little margin. We can't be sure it's reliable. When a background process on your computer starts, it might have a bigger impact than our five-percent performance boost.

What we did not test is the AOT compiler. This compiler virtually eliminates the cold-start phase. It puts Java on the same performance level as C++. Cold-starts merely take a couple of milliseconds, but the price you're paying is that there's no run-time optimization. In the long run, the JIT compiler overtakes the AOT compiler. That makes JIT the ideal tool for dedicated servers, while AOT is the tool of choice for Lambda services.

From this point of view, our benchmark isn't fair. But that's OK. The topic of this article is to check if GraalVM is ready for production.

Our Quarkus benchmark clearly passed this test.

BootsFaces showcase running on IBM Liberty Profile running on GraalVM

What happens if you're using GraalVM on a traditional enterprise-level tech stack?

By now, you can guess the answer: it just works.

There's this vast JSF project of mine (Stephan). It's the showcase of BootsFaces, dozens of JSF pages. More often than not, I run it on IBM Liberty profile. Currently, that's version 8. I tried GraalVM 19.3 with it. It worked like charm. The cold-start was 10% faster than with AdoptOpenJDK 11. Granted, it's also 10% slower compared to using IBM's J9 compiler. So the result isn't overwhelming, but it's not bad, either.

Both Liberty Profile and BootsFaces are huge, complex pieces of software, so this test builds a lot of trust. We're confident you can switch to GraalVM without noticing any difficulties.

The only troublemaker was my (Stephan's) Eclipse installation. Eclipse wouldn't start with GraalVM because it didn't recognize it as Java. By the time you're reading this article, the problem has probably be solved. However, that's why I started using Visual Studio Code as a Java IDE. It was a pleasant ride, by the way. VS Code isn't as powerful as IntelliJ, but it's much cheaper and much faster. I guess that's worth an article, too.

Twitter

The most prominent power user of GraalVM is also a slightly misleading proponent. We're talking about Twitter. They're running their platform on GraalVM for a couple of years now. They're using Scala, and they report GraalVM gives the Twitter platform a decent performance boost. Twitter is such a big company that better performance immediately pays because they need less hardware.

Here's the catch: Twitter doesn't use the original GraalVM. They've forked the project and apply their optimizations to it. Chances are many of these optimizations are donated to GraalVM, but still: Twitter tweaked their copy of GraalVM so they get better performance than the average programmer does. Maybe they even get better stability and fewer bugs.

Don't take our word for it!

That said, we encourage you to download GraalVM and to run your own tests. Currently, you can download a Java 8 version and a Java 11 version. If performance is your top priority, check out both. Sometimes Java 8 is faster than Java 11. It's also 100 megabytes smaller.

Talking about Java 11: in theory, GraalVM is already part of every Java 11 distribution. You can activate it with two command-line parameters:

Alas! You'll be disappointed. We had to dig deep to find the reason. Standard Java 11 ships with an old version of GraalVM. Have a look at The GraalVM folder of their GitHub repo. The last commit is almost two years old. It's from July 2018. So we'd rather you installed GraalVM from the GraalVM GitHub repo. That's a much more pleasant experience.

What about the enterprise edition?

If you've got the budget, check out the enterprise edition. According to the marketing slides, it offers better performance, faster bug fixes, and so on. We didn't have the budget, so we didn't even try.

Wrapping it up

We ran quite a few tests with GraalVM, so we're confident it's a decent virtual machine for Java 8 and Java 11. However, we didn't have the opportunity to use it in a customer project. That renders our confidence, well, less solid. Nonetheless, we'd be surprised if you ran into trouble using GraalVM for your Java application. Just give it a try. We're positive it'll be a smooth ride.

The other thing we were unhappy about is node.js support. Granted, we're surprised GraalVM supports node.js at all. It even does a great job at it. We were able to use the Angular CLI to generate projects and to compile them. We're deeply impressed. That's not a small feat. It's only... GraalVM marketing always leaves the impression that GraalVM already runs JavaScript faster than the V8 engine itself.

Well, that's true for small JavaScript programs. As of today, large JavaScript applications aren't the best habitat for GraalVM. That's going to improve, but it underlines the eternal wisdom: don't fall for smart marketing. Always run your tests before buying it.

'Nuff grumbling. If you're a Java programmer, go for GraalVM. It's a decent alternative, and it's going to improve over time. Plus, there are the killer features: polyglot programming and high performance in a cloud-native environment. We'll cover this in much more detail in the next three parts of this series. Stay tuned!