WebAssembly and the Future of the JVM Ecosystem by Andrea Peruffo @ Spring I/O 2026

In this talk, Andre Peruffo discusses the significance of WebAssembly in the context of the JVM ecosystem and its potential future developments. He introduces WebAssembly as a portable binary code format initially designed for the web, explaining how it enhances performance for CPU-intensive tasks by allowing languages like Rust, C, and C++ to run at near-native speed in browsers. The speaker highlights use cases for integrating WebAssembly with the JVM, such as embedding JavaScript engines and running OPA policies efficiently. He emphasizes the benefits of Chicory, a WebAssembly runtime for Java, which allows developers to execute various programming languages without rewriting applications, thereby promoting a polyglot environment. Andre concludes by predicting that WebAssembly will increasingly become a standard feature within the JVM, making complex functionalities accessible through simple Java APIs.

[music] >> Just a few after done talks, but what I'm extremely happy to get a little part of a spring community here and to talk about web assembly and this and what I think is the future of the JVM ecosystem and how things will evolve in the future. So this is my very very first spring I owe great energy, great vibe. Thank you so much for having

me and thanks so much to Sergio for organizing such an amazing conference. Thank you everyone. So, let's talk about me because I'm not very much part of the spring community so far at least and I want to spend a couple of words. I'm Andre Peruffo. I am a principal software developer at IBM. I'm actually Italian but I live in Lisbon and it's like more than 20 years

that I'm doing this job now. So I started with embedded systems, worked on PLCs and industrial machines. I went to work for banks, telecommunication companies, distributed systems, startups, many many many different kind of kind of industries and I did a lot of Java meanwhile and a lot of things on the JVM as well. We have this super packed agenda for today and since I'm the one in

between you and your beer next, we will have a burning surprise by then so that you have to stay awake and hopefully [clears throat] follow me in this journey on web assembly and we will have a great announcement by then. >> [clears throat] >> we will go through a little bit of a web assembly intro. How [clears throat] many of you don't know nothing about web assembly?

So, this is very much [laughter] good for you and we will go through a a few use cases that will show how web assembly is useful today on the JVM for your applications. We will zoom on Chickory which is the project I'm mostly working on. We will have this burning surprise and we will go through conclusions. So, what is web assembly? Just Wikipedia definition. Web assembly defines

a portable binary code format and for executable programs, but this is not the entire definition. The entire definition say states that it also define very well the interactions in between the web assembly module and host system. So, how you call a function in the web assembly module and how you expose your host system inside the web assembly module. So, the two ways on how web assembly can

interact with this host from the very definition you can see that it is very much toward embedding, not running standalone application, but it has been defined and implemented to be a specification for programs that will be embedded in other programs. And binary format is easy because it goes very well machine to machines, it's compact, machines understand very well binary. We don't so there is a corresponding text

format to to to help people understand what is going on in the program. Why web assembly born in first in first place? Web assembly born for the web platform, born for for the browsers and for the speed for speed. Because what happened is that in the browser the language that you have available is JavaScript. JavaScript is a dynamic programming language, you cannot get high speed and you

cannot run CPU intensive task on it efficiently. So, you have physical limitations on how you can run a renderer or some CPU intensive tasks in your browser and in your client side applications. They wanted to overcome this limitation and initial experiments of asm.js if you are familiar with it, they went down the path of standardizing with W3C a specification of web assembly that enable system programming languages

like Rust, C, C++, Go to be compiled to web assembly and run at a near native speed in the browser. So, once you can write a C renderer and you can run it safely in the in the browser, you have the speed and you can you can compose much better apps for for your user much nicer. So, even if you don't know nothing about web assembly, you

are using it every day because it is actually powering like a Google Maps, all the Google the the Google Docs, Excel, all the Google Suite and many other products like a Figma, Adobe and other major players are putting it in production and is running in your browsers probably every day. >> [snorts] >> Being in the browser space, you want those things to be very secure. You cannot

run something that touches the memory in your browser that will corrupt all the clients' machine that are running a browser. You want it to be sandboxed and and very secure. What does it mean to go web assembly to take web assembly and bring it to the server side? It means that you get polyglot capabilities. So, a lot of languages can compile to web assembly and you will

be able to to just reuse them on the server side. Is easily embeddable. There are a lot of different runtimes for for running web assembly and you can actually you can actually hook them up and in many different programming languages and just execute them. Is extremely portable. Is a is again one thing to to to is portable across operating system and architecture. You you have one single

target which is web assembly and you don't have any more ARM, x86 or Windows and Linux differences. And is a secure. As I told you is designed to be to to run untrusted code to to run code that you don't want to trust that comes from different users. And again is part of the W3C. Why I'm stressing it? Because a lot more applications are making use in

the in the browsers of web assembly and more and more things are becoming compatible with web assembly and we just want to to to to be able to reuse those things on the JVM or on any other server side component because is extremely convenient. When we talk about web assembly, we always talk about those two things. So, there are a lot of different languages that can target

web can target and can compile to to web assembly bytecode and then you have the the runtimes. So, you take web assembly bytecode and you execute it. At the top you can see V8 which is the the engine that powers Chrome or SpiderMonkey for Firefox etc. and there are many others like Ingo was zero and the Rust was time. When [clears throat] we talk about the JVM,

we have a problem on running actually native code. So, you can take one of engines like V8 and just hook it up on the JVM, but it doesn't provide you the same ergonomics of a pure Java application. It makes anyway your application distribute dependent on the platform it will run. You need to to cross compile your native piece of code for different operating system and architecture and

distribute the native library to be able to run it. And during runtime, the execution leaves the safety and observability of the JVM which means you lose all of the debugging capabilities, you lose all the monitoring, you you lose all the debugging tools that you are used to use and especially when a bug happen or a problem happened in the native code in in the native side of

the code, your JVM simply crashes which is something that you don't want to happen. Instead, when you stay within the JVM boundaries, you have a lot of guarantees, you have a lot of things. So, you have memory safety, you can configure the memory, the garbage collector etc. of the JVM very very precisely. You have a full isolation. So, if something bad happen in your in the native

part of your code in the web assembly payload, you will get an exception, not a the JVM crash which is very different. And you have advanced just-in-time compilation which means that your web assembly module will be optimized during execution to run faster and faster execution after execution like a normal like a normal Java program. Those programs are self-contained. You can just distribute a jar and the jar

will just automatically run on any on any on any JVM wherever you deploy it. And is easy to to run in regulated environments. You will be running you are running a probably spring boot application in regulated environments and shipping web assembly payload will be just adding a library, adding a dependency to your project. So, is exactly the same. And again we are back to write once >>

[laughter] >> and run it everywhere that comes from the JVM that was the promise with applets etc. But this is finally secure. probably we get much closer. So again, what does this mean to you Java developers? This means that you have all those fantastic programming languages and then a lot of fantastic applications written in them and there is magic. >> And we can finally execute it. Let's

start with the very first example where this approach shines and this is probably the the angle that reason the most with the people I talked to. We talk about JavaScript specifically. The situation on the JVM with JavaScript is kind of bad in the sense that you have two deprecated engines which are Rhino and Nashorn which are deprecated, barely maintained for often with CVs and problems that takes

time to resolve etc. And on the and on the other side you have if you're lucky enough to run on GraalVM, you have a Graal.js which is actually a very good engine. But you need to be on GraalVM to to squeeze all the performance out of it. So what happened? That it exists a very very great runtime for engine for JavaScript which is called QuickJS. QuickJS is

a C engine which is very small but it is already compatible with most like like most of the ECMAScript specification so is able to actually run basically any JavaScript program. Is and is done for embedding which means that it doesn't have the node or browser APIs built in but all the rest of the JavaScript can just freely run and you can expose more functionality on top of

it. So we take this C engine that someone written and that is very efficient, very small, very portable and we wrap it with our Why Rust? Rust the Rust tool chain is great for emitting WebAssembly modules. So yeah, the Rust tool chain is much superior than any other tool chain that existed right now. So it's very convenient if you want to do to compile something to do

to WebAssembly to wrap it into a into a Rust container and go on from there. And then thanks to Shopify that is running this stack in production to enable you to to have a custom actions on top of their on their shops. We have Javy which makes our QuickJS even more kind more kind to be run in WebAssembly. So they specifically have a wrapper for our QuickJS

for targeting the WebAssembly target and making it very convenient to be run. What happened is that again we need to we want to run all of this with Java and what I did is to take this amazing stack that was already available and wrap it into a pure Java application. So >> what this does mean is that you don't want to see all this complexity but what

you want to see is just a single jar that you download is about I think they just checked this like 700 kilobytes of jar that fully contains a full-fledged JavaScript engine that I haven't written. I have just did the binding to work to work to work the JVM and you can import it very very easily. For example, with JBang is just one line and this is fantastic

Java 26 that enabled me to to to squeeze a lot of in a very little place. So you can actually run JavaScript inside inside your Java application very very easily just adding and and and and using it. Use a the runner will be completely safe as the heap space is separated from from your host space and this is completely dynamic. So this means that you can run

any JavaScript payload even if your application was compiled with native image in first place. So we restore the dynamic capability of the JVM by enabling native payloads to be run again. And [clears throat] by chance so there is this project called MicroX. There is a workshop about it happening in the meantime and the MicroX is a great CNCF project which enable you to to do API mocking

basically. Serve API mocked for for your application. You provide open API, fast API, whatever and you can and you can return mocked the response. By chance MicroX is a Spring Boot application. But it's part of the CNCF and [snorts] they used to to enable their people to customize those mocked answers those mocked responses using a Groovy dispatcher. You can imagine what would be the reaction of someone

working on Kubernetes and having to write Groovy. They want to write Go, they want to write Python or maybe JavaScript but they really don't want to touch the JVM for even with a stick. >> I went there and they were looking for options to run a different programming to to write those dispatchers and I integrated QuickJS for J. Integration was went smooth and now they have a

JavaScript dispatcher that enable you to write those those little snippets of JavaScript code that will be executed in the JavaScript in in in QuickJS at the at the end of the day and all of this is fully compatible even with native image. So you can take MicroX, compile it to native image, run it efficiently, fully statically compiled and still execute dynamic payload and and JavaScript on top

of it which is a great power. >> And [clears throat] if you want this is a link to the project QuickJS. Yes, it's available offline later. No worries. Yeah. So next let's talk about Open Policy Agent. If you haven't heard about it, it's another CNCF project. OPA is a policy engine. So it enable you to run policies. This is often used for authorization on top of on

top of Kubernetes and for running authorization payload or or validation or doing those kind of job on top of Kubernetes platform. They they let you write those policies with with by using a a language which is a Datalog language called Rego and this is an example a very very basic hello world example that will allow no one but Bob to access something or to do something. And

all the stack of OPA is written in Go and this is the integration they offer you or they suggest you in a classic way. So you have a request or an event or something that goes into your service. Your service does an HTTP call to an external OPA server and gets [clears throat] the response if it can go on or not based on the policy or the

Rego file that you loaded there. But what happened is that they designed in a very smooth way so that OPA build you can actually compile this Datalog language directly to WebAssembly and execute it in WebAssembly. What does this mean for you? That you basically just cut the network call. So you don't have any more to go out and check your policy against an external third party system.

You just run it in process. This is much faster, convenient, less infrastructure to maintain, more practical even to implement and and use into your services. As an example, since we are at SpringIO, I took a Cloud Gateway and I wrote a filter for it. And as you can see it fits as the full implementation fits as light. This means that you can take an OPA policy, load

it dynamically upon when when you receive a request and execute it and execute it and evaluate on on the user input. In this case I'm getting an header just for demo purposes and understanding. So if you put Spring Cloud Gateway in front of your application and you want to do authorization, this is a very easy integration that you can do. And yeah, I have a little demo.

You can is not that fancy so it's just a GIF a GIF and if you are the user Alice, of course you will receive back 401 because your access is forbidden but if your user is actually Bob, the one that wanted to to to that is allowed to access your service, you receive 200 back with the things that got filled. Um This repository Spring Cloud Gateway was

demos comes from all the demos done for Spring Spring Cloud with WebAssembly and it contains a bunch of examples running JavaScript, C, JQ, or OPA, many different things so just for you to to to see how this integrates with a real-world project like a Cloud Gateway. Or how you can leverage it. Next, we talk about Protobuf. Uh for sure you have heard about Protobuf is very is

very much is widely used nowadays and what's the deal with it? So, my Quarkus I I work next desk to people developing Quarkus and they came to me and said, "Okay, we have a problem with Protoc." So, to Protoc is used to generate the code that you will be be using at runtime to to conduct different services. So, with Protoc, which is a C CLI, um you

you can you generate the Java code that you will be using. Uh what happened is that with Quarkus gRPC, they attempted to make the user experience really smooth. And to make the user experience really smooth, what you do is just you pack all the binary that are available and you make them a dependency a transitive dependency of your generator. And this means that just at compile time,

which is not a huge problem in in a lot of context, but this piles up to compile dependency that are up to 400 megs, which for an L word, which seems a bit excessive if you want. And they came to me and say, "Can you do anything about it?" So, uh old story new, we we we took Protoc, we compile it for WebAssembly, we wrap as a

pure Java library, and the full Protoc functionality is available in 1.3 megabytes. So, for all the architecture because it runs as pure Java bytecode, you don't have to target anymore different specific architecture and you can just run what you need on the JVM as you're used to. And compile time dependencies went down to 90 megs, which means that we saved we saved like 300 megs just by

by using this kind of things. And was the result of Protoc is byte by byte the same as the native application. So, I haven't rewritten Protoc. I haven't like like they did at Square with Wire and those other libraries. I just I have just recompiled Protoc in in a WebAssembly payload and make it available to to be shipped on top of the JVM. Uh those are the

two projects. If you want, I have I have done this for integration of Quarkus gRPC 0, but all the engine is available in Protobuf 4J, which is the base library to expose this functionalities. please be my guest to write a Spring extension for it. Next, we talk about code highlighting. So, no one wants to see code in black and white, right? You want to to to have

at least syntax highlighting when when when looking at a piece of code. You It's boring, but it's not understandable if you don't if you don't have some colors of it. And you will will say will tell me Java is a server-side application. I don't need to show this kind of code. And well, it depends. So, I have a friend which is Max, the creator of JBang for

example, that started to work on this project called sorry for my bad French pronunciation, but it be Tambouille or something like. And that enable you to to write a terminal user interfaces in Java in the same way as a Ratatouille and other and and other and other things. This makes makes it for very very fun and entertaining CLIs and And often when you write terminal UI, you

want to show the code that is inside some files and you want syntax highlighting. So, the problem come back to us. What's the problem with it? If you look at the Java the landscape, I looked around and I couldn't really found nothing. This is there is something very very little done in Eclipse in some old projects done with regex, but is hidden inside some framework or or

Eclipse or or or the IDE or whatever. So, there is really nothing. But this is a solved problem. We don't have to go through it again and again. Code highlighting is a solved problem and for example, you have those two >> things that comes up to mind immediately. The first one being highlight.js, which is a JavaScript library again with regular expression, but that enable you to to

to do syntax highlighting in the browser. And the other option is a tree is called tree sitter. Is a C and Rust library that enable you to write grammars and is basically the engine that is used behind VS Code for example. So, all the syntax highlighting done in VS Code is done through tree sitter grammars. Um We have WebAssembly. Who can stop us? So, you can write

highlight.js on QuickJS that I presented before. So, this works out of the box, but I wanted to squeeze a little more performance out of it. So, I went for I did I I I did a POC of running highlight.js just to show that it was possible, but I took the way of integrating tree sitter. And I found a library that is wrapping tree sitter grammars and making

them available with a lot of different themes. And this is called Lumis. Is a great project and enable you to do syntax highlighting for like 70 more languages and with a lot of available themes. And as you as you can see, the API that you will use to to to to use it is a super easy and super simple and enable you to do some very very

cool demos finally with some >> fancy colors and the showing the code in very in very different things. Again, Lumis 4J was done probably in less than a day. The initial version. So, it take very very little to just wrap the work of other engineers and all the effort that they put in it. Uh this is a link to Lumis 4J. If you have any use case

for it or you want to write your own terminal UI with fancy colors for your programming language. And there are a lot more stuff. So, We started from a databases. We have SQLite running running as pure as a pure Java dependency. We have JQ the command line tool that you use to parse JSON etc. We've even ported the Postgres recently. So, we have PG Lite, which is

a port of Postgres for the browser, which is running as pure Java again and again. Prisma, a Ruby parser, Bazel, the build tool from Google. Open Feature is using is using WebAssembly to ship the logic of feature flag in different SDKs in different languages. We can run CPython. We have single message transformation in the vision and much more. So, you are missing. Come. Uh and what makes

this possible is Chicory. So, let's zoom in. And what is Chicory? Is a web web assembly runtime written in Java for Java. Uh the alternative on the JVM will be GraalVM. >> And what does it mean for you? It means that uh all this magic is provided to thanks to Chicory. Uh Chicory started in 2023 thanks to Benjamin Eccleston at the time CTO of uh Daedipus. Um

and I joined the effort like 1 week after he started. and in 2023, we developed basically all the basic part of of an interpreter for WebAssembly. So, WebAssembly interpreted on the JVM. Um we realized that this was useful and very cool, but in 2024, we went over and developed a compiler for for WebAssembly. If you look at WebAssembly from far enough, WebAssembly bytecode looks very very similar

to Java bytecode. Uh so, we are almost translating one to one WebAssembly bytecode to Java bytecode to be run directly and natively on the JVM. Um we got it running. In 2025, we focused on getting more proposals and more specification compliance on this on this engine and we did a lot of applications well and some of them are the one that I presented before. In 2026, we

integrated Wasm GC, which is a big chunk of proposal that enabled more languages on top of Chicory, languages like Dart, Kotlin, or even Java. And we developed more libraries on top How Chicory is a little as I was saying that Chicory is a little different than a normal compiler in the sense that it doesn't produce a machine machine specific assembly, but it produced Java bytecode, which is

self-contained, fully secure, fully portable, just a plain JAR, and has a very nice side effect. Well, everything that runs outside [snorts] everything that gets generated out of the Chicory compiler runs even on Android. We have been told that running running WebAssembly on Android on Android the easiest way to do it is using Chicory. Um we have covered a lot of the proposal. We have work on WebAssembly.

We have threads, which is not in the spec just yet, but is still a proposal. We have multi-memory, Wasm Preview 1, Wasm GC. We started. We need to finish some details to to run it even faster and better on the JVM, but the the full specification is fulfilled. So, you can actually run stuff on it. if you are not aware on the GraalVM team, they did something

extremely interesting, and they took native image and made it able to to emit WebAssembly bytecode, and they called it GraalVM Web Image. So, you can take Java bytecode, compile it with GraalVM Web Image, and emit Now, you can take this WebAssembly, take Chicory, compile it back to Java bytecode, and you can go on and on. >> Getting Getting instances slow down because of various things, but this

works. More interestingly, what happened is that, for example, you can get a Rust payload, compile it with to run on Java, and then you have a Java application that will run on the JVM on one side, and maybe in the browser or on Node, and you can compile it with Web Image and get the same thing to run through Chicory in in [laughter] your final application. This

opens a lot It's not maybe useful for the end user, but it helped me to to to find like bugs in this integration, and now this integration fully works. Um when we look at performance, that Chicory is quite good. We started comparing it with other um with other runtimes, Wasmtime, which is a runtime for WebAssembly, and Wasm Zero, which is written in Go. And you can see

that performances are very very close in most cases. In some cases, like in Fibonacci, the JVM seems to be very efficient at inlining loops, so is even more efficient than other implementations. Yeah. And Chicory is a community project, so please come join us. We recently reached more than a thousand stars, which means a lot for a Java project at least, maybe not in other ecosystems, but well,

that's where we are, and we are open to contributors. Please come and join. And link to Chicory, please come and start a conversation with us. now, we did all of this. we believe we deliver some value, and we started to receive feedback by the user. And guess what was the biggest complaint of user? So, the biggest complaint was the sandbox to you, so everything runs really isolated.

No, no, no, no, no one cares about the sandbox at the end of the day. What people wants is just raw >> We realized that a lot of people come to the project and they forget about all this first part about safety, running things smoothly and nicely on the JVM. They just want raw speed to run their payload. That's what they want. And the problem is not

is not is not something that is easily solvable by us staying on the JVM. This is JDK 11, but there is this thing called a huge method limit, which is set to 8,000 since ever, I guess. And this means that when your function or method exceed 8,000 bytes of size, it will never be compiled by C1 or C2 or any compiler on the JVM. So, this means

that as soon as your function or method goes a little above this size, it will run in interpreted mode, and in interpreted mode is very slow. You take orders of magnitude of performance penalty compared to any compiled alternative. So, if you are not very very careful if you don't take a lot of care when you write your Java code, you will have very very bad performance just

because the JVM will not even attempt to optimize it. So, what happened what happened what for us that we are writing a compiler from WebAssembly to Java, we cannot really change the size of functions because of those are user input for us. It's not something that we can refactor or easily easily do something different. So, what I started writing Redline, which is a new compiler for WebAssembly.

And this time, as you can see, is hot, and there is fire because we need to go a little bit unsafe to go to squeeze every performance byte out of it. And Redline builds on the very foundation of Wasmtime, which is the reference implementation of a Wasm runtime written in Rust. The compiler that stays behind Wasmtime is called Cranelift. And the Cranelift What Cranelift does is it

takes WebAssembly and emits assembly specific code. Again, we are again back to the problem that we have x86, ARM, etc., Linux, Windows, but we have a compiler that does it for This compiler is written in Rust, and guess what? We can run it through WebAssembly. So, we compile the compiler written in Rust to WebAssembly so that it can run natively on the JVM, and we have our

compile-time toolchain fully accessible on any JVM. Once we have this assembly, we cross-compile it for like six different six different combination of architecture and operating system, which are the most common, and we bundle it in the JAR along with a Chicory version. So, if you are on a supported on a on a supported architecture, you will get all the speed. If you are not on a supported

architecture, you get Chicory, which is anyway very fast, and will run anywhere the JVM will go. >> But once we have a JAR, what happened is that there is a little bridge of magic, which is done with Panama on Java 25 plus, and we have a fallback using JFFI, which uses JNI behind the scenes, but is just a fallback to for retro-compatibility if you can't use Java

25. But with Java 25 plus, you you still don't have any dependency, so you can run WebAssembly with zero dependencies on the JVM thanks to this. And the last bit of the equation is M map. So, with Panama, what we do is if you are not familiar with M map, basically, you are reserving an area of your memory, you are dropping there assembly code, and say to

the machine, "Okay, just execute it." >> This is unsafe, as you can imagine. This is native access, but this relies only lib C standard library. So, this is available on any machine, and this runs really fast. So, we took again our benchmarks, re-ran them, and as you can see, the numbers are very very close or even better than runtimes. So, we are in the same order of

magnitude. Again, don't take those numbers as something big. They are being run on GitHub Actions, which are noisy, We are doing good. And I can share even more, and we have been running more payloads, and we got much speed up, especially on some applications. And this is Chicory Redline, and this is the very first time I'm showing it out in public. >> And I'm very happy of

it. Check it out. >> Yes, conclusions. We don't want to rewrite our applications. It doesn't make sense that you rewrite JQ for for for for the JVM just to have the same semantics of the language that that parses JSON. It doesn't make much sense but you rewrite SQLite in Java to to to have a database. You don't want to rewrite those things. You want to reuse everything

on the JVM. The JVM is a perfectly viable runtime that enable you to to run things safely and fast when you want and depending on the trade-off that you have you can take you can take your party and you can you can decide how to run those things. So you can happily just merge and take different languages, compile them to to web assembly or run them on

top of the JVM and you will have one runtime to run any different language without without without a trouble. What I see coming is that a web assembly is not a night technology that you will see along with AI and whatever but is something that is spreading. This is happening for in the browser. Most NPM packages are containing web assembly as of today. The same will happen

on on the JVM slowly and steadily. So you will have web assembly payloads hiding behind behind behind the Java APIs that access the functionality. You don't need to write a Rust program that brings you a functionality that is useful for business or that that is useful for for your application. You can just embed it, ship it and run it from full Java application. And thank you everyone.

>> [applause] >> We have 5 minutes to take questions. If there is any. Oh. Yes. Yes. Yes. Yes. So it very much it Can you hear me? Oh, okay. Sorry. It very much depends on the I think is this is not working? Anyway. Yes, we did it. It very Unfortunately, so this very much depends on on what your program is doing behind the scenes. But in general

web assembly promises near native performance and we can get to run Usually payloads in order of magnitude of 1x 2x the native one. A part a part Yes, it's working again. Apart from that you you you have some payloads that pay more a higher price on top of the JVM. For example, when you have a big parser like a the SQLite parser for queries or the CPython

interpreter, you know, like those huge functions that you can that are very very hard to split or break. Um there you pay a higher cost running purely on the JVM and that's why I developed the Redline that will bring back the near native performance even to those payloads seeing very very good numbers on real world payloads running running on it so far. I hope this answer. A

good? Thank you so much for being here.