# WebAssembly on JVM: Strategy, Safety, and Performance

**Podcast:** The InfoQ Podcast
**Published:** 2026-08-03

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16th through the 20th, 60-plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at QConSF.com.
I'm in software development since 20 years now.
I have done a ton of things, especially on the JVM with Scala in the past and with Java more recently.
Bring a WebAssembly on the JVM.
That's probably what you have heard more recently, Paivi.
Yes, exactly.
But most of our conversations in at least the last two years were very niched, if you want, even though it's debated about how nichey it is.
And that was mainly about WebAssembly and the fact that you joined the wagon of the guys that think that WebAssembly shouldn't be in the browser, just in the browser, and we can use it on the server side, given your pedigree with Java.
But let's take it one step at a time.
Why do we want to take WebAssembly out of the browser?
Because it was very known for its JavaScript side.
And let's take it to that.
What's WebAssembly?
Who doesn't want a free lunch?
I do.
So everything that has been developed for WebAssembly, the browser, is theoretically reusable over server-side.
And on the front end, following the specification of W3C, we have a WebAssembly that is used in each and every application that we are using.
Nowadays, if they are complex enough, for example, it powers Google Maps, the entire Google Docs suite and their productivity tools, they are all backed by WebAssembly.
So what happened is it bore for the front end to give almost too late of a speed to some boxed environments in the front end and in the client side, but everything that has been built.
for this platform can be reused on the back end.
And I think this is the most powerful thing.
This was one of the main reasons that drive me to look more heavily into WebAssembly.
I don't like to rewrite stuff.
I do enjoy to reuse as much as possible.
And when I looked at the technologies that were available, WebAssembly stand out as the tool.
that enables you to have a bigger and wider impact on what you're doing.
Last year, I have been able to deliver and release databases, programming languages like C, Cpyt or JavaScript, to enable running various kinds of Rust and C libraries, a protobuf.
You can run a ton of really useful things without having to rewrite them.
So with just a very, very, very thin wrapper layer, and you don't go outside of the JVM with all the headaches that the JNI has.
So that's a pretty natural choice, if you want, to enable more workload and more interesting stuff on the JVM.
Okay, so in those particular cases when you normally call from Java native libraries, Now you can just use WebAssembly to just put together and make your life easier.
Maybe not just easy, but I think it's safer because that's the big ask and the big promise of WebAssembly.
Yes, yes.
And not only safer.
Safer because it runs, of course, with a different heap.
So all your program is protected against the CVs that the libraries that you are embedding will have, but also around the portability.
When you have JNI, you have to pre-compile your native library for all the target OSs and architectures.
But with WebAssembly, you have just one target.
And targeting WebAssembly means you have a fully portable JAR at the end of the day that you can reuse wherever the JVM can go.
So you have portability, you have safety, and it's far easier.
been doing JNI where they crash your JVM and you have all kinds of misbehavior.
I have done JNI for enough years in my life.
Okay, fair enough.
So now it's a vengeance against JNIs and you showed them how the things are going.
I have to admit, I wasn't paying attention to what happened in the WebAssembly slash was in space.
I know that one year ago, when I think the last time when we met in person, there were a couple of big things that were happening.
Maybe let's do a summary where WebAssembly is in terms of the standard and what happened on the WASI side.
And also probably your pet project, Chicory.
Well, it's not pet anymore because it's a full-scale project.
It already has, I think, two, three years since it reached version one.
But let's take them one by one.
Where is WebAssembly now?
What are the most important things that will happen in the WebAssembly slash WASI space?
Because obviously, in order to have something useful, the WASD interface to the system is quite important.
Otherwise, we wouldn't be able to do many things on the server side.
Where we stand on the WASD side is that the core specification has been basically completed.
So they integrated all the proposals, what was called the proposal of WebAssembly, that were necessary to get more languages to run on the platform.
So WASM GC, garbage connection, is integrated as well as multi-memory, as well as many other.
And those proposals create a solid foundation.
It's called the WASM 3, the A.3 release.
And it's the core foundation that enables anything else on top of WASM.
In Chikori, we are compatible with all those specs or most of them, whatever makes sense on the server side.
And we have also an initial implementation of WASM GC.
What does this mean?
That you can run, again, on the JVM, going through WASM, languages like Scala, with Scala.js, that can compile to WebAssembly GC, or Kotli, or Dart, or those kinds of languages.
So we have enabled a new class of languages to be able to run on top of the WebAssembly engine.
Talking about WASI, the system interface is being completely reworked.
So it has been almost finalized at WASI P2, and they are working on WASI P3, which integrates the component model, and the tooling and the tool chains are picking up the job to be enabled with it.
What does component model mean?
It means that you can write...
the interfaces of your program in a WIT file, in an interface file, and generate all the rest to compose your application with any other WebAssembly components, which is really fascinating.
And I'm looking forward to see how this plays in practice when we will have a lot of different modules coming from different ecosystems and working all together.
So that's pretty exciting work that has been done.
I cannot wait to see how it plays out.
So if we look in terms of the versions, and not only at Chico in the Java, they are quite advanced.
I'm talking now about WebAssembly targets for a lot of the other programming languages.
Wazero, I know this is one of the seniors of the space.
Chicory is not far behind because it's already a couple of years now since it's already number one in terms of versions.
But do you know anything about the adoption in production?
Is it used and where is it used?
To just get more a bit concrete in terms of use cases.
The biggest use case for WebAssembly in general has been exploited by all the major CDN provider.
So if you look at Cloudflare, Fastly and Akamai.
They basically all built in-house or bought companies that were able to run WebAssembly workloads on the edge.
This means that the offering of durable objects by Cloudflare and compute at the edge by Fastly and Akamai as well, they all run your code on WebAssembly, which means that there is no other technology that is able.
to run this kind of workload in such small hardware and with such high density and security for the provider.
So the providers are able to let you deploy your random applications on their infrastructure and they are able to run it thanks to WASM because WASM is a very lightweight sandbox of WebAssembly plays a great role.
in this picture and enables you to run whatever workload you want without risking to affect the underlying platform.
So that's where WebAssembly already won.
In the front end, of course, is used by all major sites that has some CPU that has its task to be done.
Like if you need to do any rendering, any kind of cryptographic algorithm or any kind of CPU-bounded computation, you are probably using WebAssembly the NvCs.
And on the server side, there are various usages.
For example, you touched on Wazero.
Recently, they announced that Wazero is integrated in Elm 4.
so that you can customize the behavior of Helm by injecting WebAssembly plugins.
So it is enabling pluggability of different systems on top of the platform.
For example, talking about Chikorit Power's CPython UBF function in TrinoDP, which is a SQL database written in Java that is used for...
when you have a lot of data and it's a great data bit and it enables you to write CPython functions powered by WebAssembly in production since a couple of years now, since our first 1.0.
Nice.
Also, I know that a couple of months ago, you had a bit of a collection of interesting things that you put together in running on Chicory, just to see where it goes.
One of the...
Very important aspects for the global community is you managed to put Doom, the vintage game, to run in WebAssembly.
I suppose there are other less important things that you managed to achieve, but this is quite important.
Maybe you can share a bit about this experience and if there are others that you want to mention.
Yeah, yeah.
Actually, Doom was one of the first workloads that we got to run and we were pretty excited about.
did a knackathon and portrayed a do to run on Graal Wasm, which is by GraalVM folks, and we got it to run on Chikori pretty easily at the start of the project.
One of the other projects that are really close to my art is Prism.
Prism is under the Ruby organization on GitHub, and Prism is a Ruby parser written in C that is powering JRuby.
Basically, we have been compiling this Ruby parser to WASM and executing it in Java since day zero.
Basically, we have both friends who are Charles Snatter and Thomas and Ibo, which are the leadership of JRuby.
They want to enable JRuby to run anywhere, of course.
And the first thing that you have to do when you want to run JRuby is to parse its syntax.
But the syntax of Ruby is done for humans and is extremely hard.
to parse it.
So what happened is that in the various ecosystem, multiple parsers have been rising and falling along the years.
And very recently decided to invest all their money into making one single parser that will be the official one.
And this one is called Prism.
And we wanted to be able to parse Ruby syntax on any JVM without having to install native libraries.
That's why we started with Chicory.
And the cool part is that this project is following along the years, the evolution of Chicory.
This real-world C-Parser was one of the first payloads that we got to run on the interpreter at the very start.
We improved performance 10x.
by using the compiler to Java bytecode.
And I recently released a new compiler, which instead produces a pure assembly that again increases 10x performance again on Prism, making it very, very competitive with the native version of it.
This is just one of examples.
millions of other examples if you want.
I know that you're a chatty Italian and I'm a chatty Romanian, two Latins meeting to talk, but one million is a bit too much.
So if you have any other ones that you want to push forward, I know I remember the one with Prism.
I know that it was mid last year.
You're quite proud of it because it was the first one that was really making something important on web.
There is one that I really want to mention, which is a quick JS.
So if you look at the Java landscape, there is basically no way to run.
JavaScript inside the Java application without using a non-deprecated library because Rhino and Nashorn are both deprecated.
The only alternative is Graal.js.
If you are on Graal.js already, great, go for it.
But if you are not on Graal.js, it might not be a great fit for you.
And on the other side, we have Shopify, which is a big portal that enables you to run your shop and customize it with WebAssembly functions as invested in a little engine called the QuickJS.
This little engine called QuickJS is written in pure C and there are Rust bindings.
And thanks to the Java project by Shopify, it is extremely easy to get it to run on WebAssembly.
So I took it, I embedded it into Java interfaces, and I got to apply it in a few projects.
For example, Microx is a project for doing API mocking, which is part of CNCF.
And it happened to be a Spring Boot application.
They wanted to integrate with an external language to let the user plug in their behavior, and we looked it up.
very quickly, QuickJS, and provided the functionality.
It was quite amazing because last conference, I was giving a talk in one room and in the room next to mine, guys from Microx were teaching people in a workshop how to use JavaScript on top of their platform.
They were using the functionality without people noticing.
Because this is something that WASM is probably doomed to.
It won't go for the hype, but it will power.
underlying libraries that would be otherwise impossible.
Okay.
So the key takeaway from here would be that if you want to incorporate in JavaScript, for instance, well, anything coming from the JavaScript ecosystem in JVM safely, WASM is the way to go.
And I cannot pass this topic to just underline our age.
given that we both know what the rhino is in Nashorn is, because Nashorn was closer to the current moment, but rhino was back in the day, maybe more than 10 years ago.
I don't remember exactly when, but let's say we are wiser.
If you want to fall apart on this story, it's that at some point, talking about rhino, a rhino tries to stay.
on the wave of the latest hack must-create specification.
But WebAssembly is part of that must-create specification.
And they have to be the WebAssembly engine behind the Rhino.
Rhino already means just the interface, but behind the scenes it actually is WebAssembly.
Okay.
Probably it's the inclination of the younger generations for vintage games.
So it's like you see the younger folks having the Marios in their hands.
Something that I wasn't expecting is that on top of Wasman Java, a lot of people coming from Minecraft came to the project.
That's interesting.
I wasn't expecting so, but it happened to me quite a few times to debug, you know, graphical user interfaces showing Minecraft mods and stuff that I had no clue about.
That's interesting.
It seems to be a quite good educational path.
A couple of weeks back, I was talking to Alex Zenla, the CTO and founder of Edera.
And she was pointing towards Minecraft being the starting point of her programming career.
And that made her think about several stuff.
And she was comparing the Minecraft world.
Well, I don't know what they're talking about, Andrea.
So we are two in this conversation.
So I'll have a conversation with...
with Alex and she will probably explain more about it, but it seems it's very lucrative.
So yeah, maybe we should look into that.
Oh, really?
Okay.
You mentioned the workshops and I think two years ago I was in your neck of the woods, well, more or less in Coimbra.
You gave a workshop there, but also a talk.
And I remember that in your workshop, it was putting together a couple of things as a parcel.
So maybe...
In the end, that's what chicory is.
If you just break it down to the basic stuff, it takes things on one side and then spits other things on the other side.
So I know it's over simplified.
So that's why I want to invite you to tell us what actually WASM runtime means.
Yeah, yeah, yeah.
So we have different layers where you can execute the code written to WASM.
So the first one that we implemented is a pure interpreter.
A pure interpreter will take instruction by instruction from your WebAssembly program or function and will execute them directly on the JVM without doing any kind of pre-processing.
This is extremely portable in the sense that it is self-contained and it is fully built.
on the standard library for us.
So this is extremely portable, can run on native Beam, Ijo, can run in the most strict environment and works everywhere.
The bad side of it is the fact that it's extremely slow.
We are not applying any kind of performance improvement on top of the interpreter because it is anyhow inherently slow.
It has to process instructions one by one.
without a chance of getting JVM C1 or C2, just-in-time compiler, to kick in and improve the performance of the WebAssembly payment.
What we have developed after that is a full-blown compiler from WebAssembly to Java bytecode.
If you look from far enough, you can see that WebAssembly bytecode and Java bytecode, they look very, very similar.
WebAssembly...
as a structured control flow while it's unstructured on the JVM, but we are going from a more constrained environment to a less constrained environment.
So everything is not a really bad transformation, and we do almost in one pass, we do a direct translation from WebAssembly to Java bytecode.
What we observed is that once you start translating all your functions into generated Java functions that will map...
the original WebAssembly, they will start to get optimized by the just-in-time compiler C1 and C2.
And they will eventually become very, very fast on the JVM after a number of iterations and almost match the performance of native compilers that will target assembly.
This is the second tier, and this compiler can run both at runtime by linking the new program.
using a very, very thin layer of reflection that you needed to enable if you want to run in a restricted environment.
Or what we are using most of the time is if your WebAssembly payload is always the same, imagine a quick JS.
The engine is always the same.
So you just need to compile it once to WebAssembly.
And then from WebAssembly, you compile it to bytecode.
Once you have the bytecode, that bytecode is fixed.
And you can just...
take it, ship it, and reuse it without having to do an additional tweak or two on top of it.
That said, what happened is that I have been pitching the fact that running everything fully in the JVM is a great strategy and really great for your application that will not cause any harm or any anger of your program.
But people were constantly looking for performance.
We got a number of reports where people tried to run things on the interpreter or even on the compiler, and they said, okay, this is not as fast as OneTime.
This is not as fast as V8 or the browser.
Given that experience, I wanted to do the next step, so I have a new experimental compiler that got announced last spring, where we actually rewrote the compiler, but not rewriting it from scratch.
runtime for WebAssembly written in Rust, and it uses behind the scenes a compiler from pure assembly, machine-specific assembly code, which is called CraneLift.
Instead of doing the entire job of writing a multipass compiler ourselves and embarking in this multi-year project, we just took CraneLift.
compiled it to WebAssembly itself because it's just pure Rust, so we can reuse it in pure Java again, and using this CraneLift compiler to pre-compile to specific assembly of your WebAssembly program.
In this way, we have performance which are basically the very same as running most on the wastime, which is the state-of-the-art runtime in WebAssembly land.
So this gave us the last mile of speed without having to ship any native library because we are not linking against Westtime, but we are just basically reusing the compiler from WebAssembly that stands behind Westtime.
If it will be to rewrite Chicory, what will be the thing that you'll do differently?
I know that one of the things that...
you mentioned out initially was the fact that Chikor is pure Java.
This comes from, let's say, the zero family, because there are plenty of people that are obviously now zero dependencies is quite important, as we see a lot of problems occurring on the supply chain attacks and so on and so forth.
But I spoke with Gunnar Morling not long ago, and he was underlining his new project, Hardwood, that is a library that has very small number of external dependencies.
So it seems that this is getting more and more important these days when people are actually caring about these points.
Well, I don't know what I will do differently in Chikori in the sense that we have been developing it with a safety in mind first, and then we got to performance, which is, I believe, still the most useful path for our users.
Everything that is running on top of Chikori depends on...
very, very limited number of external libraries that are built themselves on top of the Java standard library.
So there is very, very, very thin dependencies.
And even the code that gets generated is usually much smaller than the original WASM.
So I think at the moment we had a very, very good runtime.
with performance that are matching the state of the art and with a security and with a history of being in standard Java, which is great for the project.
Yeah, not sure what I would do different.
Well, that says a lot of things because you are very opinionated and you have an opinion about most of the things in terms of programming.
So that says a lot, Andrea.
So it seems that you're very happy with what you guys managed to achieve.
I don't know if you know about that scenario.
If not, I'll just put a couple of accolades on my shoulder.
But I was speaking not a couple of weeks, months ago with Martin Kleppmann.
For the audience, Martin Kleppmann is the guy that started the big deal on data-intensive applications.
He's wrote the Bible because it's so thick.
And he's now quite involved with Local First.
And he was a consultant also for the Blue Sky Protocol, actually the protocol behind it.
So in terms of distributed systems, he's one of the guys that knows actually what they're talking.
And he was mentioning about one of the libraries, well, actually the library in terms of local first software that you can build around it, auto merge.
And I was like, okay, what are you doing?
It's like you have so many different scenarios.
And it's impossible to create an SDK for each of them without having a core.
And it will be hard to port it.
And he was just very confident, very calm.
And he said, well, it's easy.
We build auto-merge in Rust.
And you just compile it as WebAssembly.
And then you have so many options in pretty much all the languages.
And then off you go.
And that was quite nice.
Because as you mentioned, WebAssembly is quite big in the cloud space.
I spoke, I think, last year with some of the guys from Scaleway.
I think they were working at that point.
So it seems there are two ways in the cloud development space.
One of them is to just go with micro VMs.
And some of the people are going with Firecracker.
And that's one of the way.
And the rest of them are going with WebAssembly.
And I think another interesting conversation I had was with Max Korbacher.
He was one of the guys behind the WebAssembly run-up on Kubernetes.
Thank you.
SpinQ, exactly.
And he said, okay, if I would like to have something very efficient in Kubernetes space, you have a couple of loads that you can run them in Kubernetes.
And then in the small cracks of the space that you still have in terms of memory and CPU, you can just run a couple of WebAssembly jobs and then you'll have a very efficient way of looking at it.
So it seems that there is a whole ecosystem and there is a lot of symbiosis going on and that's very nice to see happening.
There are many different ways to employ WebAssembly nowadays, but something that sounds very familiar to me is what Krepman said, that they will write in Rust and deploy anywhere, which sounds very familiar with what they are doing with Open Features and Spotify Confidence.
So those are two flags.
as the case for enabling and disabling flags into your program, and they need to add the same code logic for the flags to be distributed across a lot of different programming languages, which is Java, Go, and native languages, and Zwift, and whatever.
And the path that they are taking, or they are trying to take, is to add this initial subset of rules written in Rust.
And that's the case that just run a WebAssembly runtime into the specific ecosystem.
This seems to be very portable and very efficient for those kind of workloads.
Well, we definitely covered a lot of things that you can do with WebAssembly.
Now, are there any counter applications what people shouldn't do with WebAssembly because it's either too big of a deal or it's something that will not be efficient out of what you know?
What we enabled recently with WasGC is the fact that you can take a Java application, compile it, for example, using WebImage, which is a version of native image by GradvM folks that will emit a WebAssembly.
And once you have WebAssembly, you can translate it back to Java bytecode and run it on the JVM.
So despite the fact that this is possible today, it's not something that I would encourage people to do because each and every step, each and every translation, increase a little bit the number of bindings and the number of embeddings that you need to run the original program, making it slower.
But the fact that this is possible is still very cool.
WebAssembly is very, very opinionated and good.
memory model that prevents you from CBEs using a separate heap.
And so in any application where you want to run a piece of software which you are not confident about or you really don't want to crash your machine around that piece of code, WebAssembly is a perfect fit.
For what is not clear there, at the moment, for example, it doesn't have any notion of concurrency or parallelism.
This is a no-go as of today.
So if your application needs a lot of performance, and most performance are achieved by scaling horizontally.
When you're a machine, this is not something that WebAssembly alone can give you as of today.
Okay, so that means that if you want to do something that you want to have guaranteed single thread, just drop it in the WebAssembly, run it in the WebAssembly, and that's guaranteed.
Other than that, if you didn't need that, you have to take care of that abstraction yourself.
So probably just break it down.
just build it in different WebAssemblies and then you do the orchestration in the programming language that allows doing that.
And actually, come to think about it, this year at QCon, there was a guy and he was talking about this exact thing and he said that because he wanted to have guaranteed that he's running only on one thread, he just dropped everything in WebAssembly and that gave him that guarantee in safety and having it in the sandbox.
And as pretty much every project that we speak about, I'd like to close talking about the community because obviously you're very involved.
How should people come and approach if they want to contribute?
And after that, I know that you have an announcement that you would like to make public as well.
Yeah.
Come and talk to ASM.
We have a Zulik channel, but there are also issues and peer requests.
So just open an issue, try to speak with ASM.
It's pretty easy.
We welcome contribution from all around.
So just open an issue or say, we're trying to use this technology.
We will try to do our best to support the use case and get you started having WebAssembly running in your application.
Talking about big announcement, yes, we do have one.
It is the fact that we are going to fork Chicory under the Bytecode Alliance organization, and the new name is going to be Endive.
We have tried to talk with Dailipso.
Unfortunately, we couldn't make a deal for claim transfer of the project, keeping the name, but the same maintainers.
of the old project will be on a dive and will be maintaining the new runtime that we hope to release very, very soon under Bytecode Alliance.
This brings together a bunch of very good things.
So the project got closer to the community and we hope to get more individuals and people contributing to the runtime.
And this is detached.
from any specific company.
So we go under a foundation so that everyone would be free to contribute instead of contributing to a single company.
And we are going to comply with all the more restrictive roles of Bytecode Alliance that is helping us making the runtime as secure and available as possible on the JVM.
So moving on, I have to change the botanical perspective from chicory to endive.
And I have to give the story because at some point we were discussing, it was like chicory is used in Romania as well, used to be used in Italy as well to make something that seems like coffee that has really shitty taste.
Yeah.
And now we are keeping the botanical one.
Thank you, Andrea, for your time.
Good luck on the new...
challenges and to grow community around Endive.
Thank you.
We hope for the best, but we are pretty sure and confident about this move because all the old community will come along and we will be able to deliver a lot of value on top of the GVM as we are already doing.
Thank you.
Good luck.
Thank you, Olympia.