Tag Archives: graalvm

WebAssembly for Java developers

What is Webassembly

A lot of things have changed since the first web page was published. Back in the days it was a static text file with some html markup. For the last so few decades web pages evolved to some really thick clients allowing a lot of interaction and having a lot of functionality running in the browser on the client side. There was only one issue in this evolution – the only way to develop this functionality was using JavaScript. This scripting language, designed exactly 24 years ago, was not designed to be used to build such heavy or involved functionalities. As a result, today’s web faces a lot of performance issues and is really bound to one and only technology. Modern browsers sometimes do real magic to speed up the performance of web pages, but it is obvious, We should not try to work around the technology limitations by throwing more hardware, compute and memory resources at it. Every time we load a web page, we load HTML, CSS and JS data, we parse it, create AST, optimize it, compile or interpret it. It is a huge waste of resources.

Since it is really hard to break de-facto standards, W3C has created an extension technology called WebAssembly. We should be clear here – this is not a full replacement of JavaScript, but an extension, focused on high performance.

So, according to Wikipedia, WebAssembly (often shortened to Wasm) is an open standard that defines a portable binary code format for executable programs, and a corresponding textual assembly language, as well as interfaces for facilitating interactions between such programs and their host environment. The main goal of WebAssembly is to enable high performance applications on web pages, but the format is designed to be executed and integrated in other environments as well.

Wasm code (binary or bytecode) is intended to be run on a portable virtual stack machine (VM). The VM is designed to be fast, to parse and execute than JavaScript and to have a compact code representation. A Wasm program is designed to be a separate module containing collection of various wasm-defined value and program types definitions expressed either in binary or textual format (that both have a common structure).

Except in a virtual machine, wasm can also be compiled to native binary (with 3rd party compilers), and this is an easy way to release something that is not usually native as native, as long as it doesn’t require heavy runtime libraries.

WebAssembly is a fairly new technology and its development is in progress. But there already is an MVP (Minimal Viable Product) implemented in the most of the browsers and available out of the box. But, to make it really worldwide standard, we need some more time!

There have been around 40 programming languages reported to support Wasm as a compilation target. Java and Kotlin are among them!


Various tutorials are available in YouTube and other platforms for better understanding WebAssembly. It is strongly recommended to get more acquainted with WebAssembly before reading this article.

What about Java?

Let us try to create a WebAssembly from Java code. For this we have several options.

One of them is JWebAssebmly, which is is a Java bytecode to WebAssembly compiler. It uses Java class files as input. That it can compile any language that compile to Java bytecode like Clojure, Groovy, JRuby, Jython, Kotlin and Scala. As output it generates the binary format (.wasm file) or the text format (.wat file). The target is to run Java natively in the browser with WebAssembly.

To export a Java function to make it accessible from JavaScript, you must add the annotation de.inetsoftware.jwebassembly.api.annotation.Export.

As a result the following wasm will be generated (text representation):

To import a JavaScript function to make it accessible from Java, you must add the annotation de.inetsoftware.jwebassembly.api.annotation.Import. The method can be declared native or can have a Java implementation which will be ignored on compiling.

The project is very young. It is only version 0.1 so there are a lot of limitations.

Another option will be TeaVM.

We can set it up as s regular maven/gradle dependency:

Write some Java code of the stuff we want to export as a Wasm binary. @Export annotation tell us that this function will be visible from JavaScript

With a maven plugin we specify where to export the generated WebAssemblies (take a look at the TargetType):

Then just prepare the html file:

And the JS file:

And we are done! Now we can code in Java, compile it to wasm, and run it on the client side!

You can play with this code here https://github.com/dalexandrov/WebAssemblyFromJava

How about Kotlin?

They did it their own way. Since Kotlin has an experimental project Kotlin/Native, which has the compilation target of LLVM, it serves as a base to generate wasm binary out of it.

We should only specify a build target of “wasm32” in our gradle build script and as a result, on the output, we should get wasm binaries and a JavaScript wrapper to work with this assembly.

This project is still experimental and there are a lot of thing to be done. Unfortunately, the documentation is also “in progress”, so you will need a little hacking to play with it. But it is a lot of fun!

Can we use Webassembly from Java?

On the other hand, Java can also “consume” WebAssembly, or to be more precise GraalVM can do this.

In his article Aleksander Prokopec has announced that GraalWasm currently implements the WebAssembly MVP. Further reads here: https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-in-graalvm-25cd0400a7f2

As a conclusion..

As a wrap up, we can say that WebAssembly is a very young, but a very powerful technology. It is still in MVP stage, with a lot of specs yet to be implemented (like multithreading, SIMD, etc).

But even now WebAssembly can run with speeds up to 1.2x native. And even now we can offload many server-side activities to the client’s browser and avoid performance issues. And we are able to do this from Java world.

Additional resources:

My talk about Webassembly and Java https://www.youtube.com/watch?v=93z9SaLQVVw

Further reading about Wasm and graalVM https://github.com/neomatrix369/awesome-graal#wasm

Quarkus: a blast from the future

Yep, Quarqus has definitely exploded just few weeks ago. As one of my friends said, it was marketing lvl8080! Just listen to the slogan – “Supersonic Subatomic Java!”. “A Kubernetes Native Java stack tailored for GraalVM & OpenJDK HotSpot, crafted from the best of breed Java libraries and standards”. Damn, so many buzzwords in one place! The twitter literally exploded as well. Literally everybody twitted about Quarkus.

I said – nah! Yet another microservices framework. There are many available now. The choice is really big. So, I almost ignored it. I’m honest here. Still the last Sunday I’ve downloaded it and played with some examples. My first experience was a failed build. I’ve submitted an issue in GitHub, and it turned to be my local maven issue. The fix was just to upgrade it. But as result this issue opened a discussion, and very same Sunday a maven version enforcer was added. The power of OSS! There are no weekend in OSS! Kudos to the team!

The twit flow nevertheless continued to appear in my feed. This somehow forced to open the Quarkus website and explore more. There was one logo that grabbed my attention:

I said – mmm MicroProfile. Lovin’ it! So it looks like I may try to pack a microservice (which is not Spring) in a GraalVM native image.

Ok, I need to try! This thought came to my mind about 3 a.m. this Thursday. Well, technically it was Friday already…

Luckily enough about a month ago we have deployed some CSV aggregation service. Yet another stage of some fancy bloody enterprise infinite process to generate some invoices. We have made it the most modern way using only MicroProfile specs, on WildFly server, running in some OpenShift pods (yes, we have a lot of RedHat licences). Mmm, a loot of cool buzzwords as well!

The service itself was completely stateless. With three rest clients we gather some data from there other services, mash them up in some CSV and serve it as a plain text on rest request! Technically it is insanely stupid! … making it the perfect candidate to be tested with Quarkus. By the way, all of the pipeline is still under development, so thus we’re not going to ruin someone’s bill and invoice.

Still the service has to work under some pressure. Thus OpenShift scales by adding pods. Since the service is stateless, we are totally ok with that! We also don’t have to care about rest providers from the other side. It’s their responsibility to scale 🙂

So, now comes the fun part!!! I’ve started a new project by copying some of the Quarkus quick–starters. Yes, I can generate a pom from an architype.. but I’m lazy.

I then just copy-pasted the code from my old project.. and it shined red.. Especially the the MicroProfile annotations.. ah. What’s wrong? 3 minutes of googling told me that for the MicroProfile stuff I need to add some Smallrye Quarkus extentions.. Ok, copy–pasted in the pom.xml.. Yay, the red is gone.

mvn clean package


Ok, you made me sweat! Now let us:

mvn quarkus:dev

.. and .. http://localhost:8080/api/v1/invoicingRXT/1253211 (some contract)

AND I HAVE THE RESULT! That’s a WOW!!! This was one the fastest migrations I’ve ever done! I LOVE STANDARDS! Long live MicroProfile!!!

Ok, I have earned my coffee. It took me.. 17 minutes. Yes, this was mostly copy–paste, but look how cool is that!

… But, thats not over! Quarkus documentation says if I add -Pnative to the maven build command it’ll produce a native image! Let’s do it! Luckily I had already setup the GraalVM installation.

mvn clean package -Pnative

Waiting.. 1 minute… 2 minutes.. BUILD SUCCESSFUL! Lovely! Yes, it takes some time to build an image! I should admit, that the business logic code was written in quite straightforward way, without any fancy constructions, just some POJOs. There were no GraalVM specific issues.

Now let us just run the executable:


and the service is up and running in about a second! Although the console says the startup time is 0,212 sec. Technically from the run command to running service is about 2 seconds. THAT DOESN’T COMPARE to ~49 seconds startup time of the WildFly server..

Ok, now lets go to http://localhost:8080/api/v1/invoicingRXT/1253211 and what I see:


Something went wrong!!! Why the example from the quick-starters work? Hmm… It looks like I’m missing one annotation over some classes – @RegisterForReflection. Reflection works a little different in GraalVM. Building it once again. Waiting another two minutes. Oh, how can two minutes can last so long..

Good! BUILD SUCCESSFUL! Now lets go to http://localhost:8080/api/v1/invoicingRXT/1253211 and what I see:


IT WORKED!!! (Now imagine the famous Dexter from Dexter’s lab cartoon shouting this loud). That is so damn cool!!!

Картинки по запросу dexters lab it works

Nice! It’s been 42 minutes since the beginning of the experiment (coffee break included)!

Ok, now let us go back to the OpenShift setup. It will be nice to see if it’s ok in our test environments under some pressure. After making some yaml permutations I’ve rerouted 10% of the traffic to go the new native image pod. After 4 hours watching it work I see no errors! Only sometimes I receive some messages from surprised testers like “Something’s wrong, some pods start in 3 seconds only…”. And I say “Haha! This is magic.”

Now some intermediate conclusions:

– WildFly 78 Mb image, Native 21 Mb image;

– WildFly ~49 seconds start-up, Native ~2 seconds start-up time;

– WildFly ~300 ms per request, Native ~270 ms per request (we are dependent on other services).

– Wildfly ~359 Mb RAM (serving 1 request), Native ~22 Mb RAM (serving 1 request)

Lovely! Just, Lovely!

What can I say – Quarkus is definitely a good thing to play with. It showed extremely well in (almost) production code. Yes, I know the example is really stupid, but that’s a real world demand. The migration took me about 40 minutes by just copy–paste. I love standards!

The coming Monday I’ll make a full native setup, we’ll see how it goes! May be even in production soon..

Disclaimer: Sorry, I can’t share the code. It’s corporate..