CODEWITHSUNDEEP
javascriptjvmwebassembly
Jawahar
Jawahar

Reputation: 4885

Why the JVM cannot be used in place of WebAssembly?

As far as I understood, JavaScript cannot be compiled ahead of time because of it's dynamic nature. So Interpretation and just in time compilation happens at run time, that affects JavaScript performance. So WebAssembly comes into picture. Languages can be compiled ahead of time into intermediate format (WASM). This gives good performance since there is less runtime overhead.

My question is why JVM cannot be used in place of WebAssembly VM. Java compiled into intermediate format (bytecode). This byte code can be given to browser and JVM can execute it. JVM also supports JIT which helps to achieve near native performance. 

So what is the need for new WebAssembly. Why can't JVM be integrated into browser and achieve high performance by leveraging the existing most popular Java language.

Upvotes: 71

Views: 15017

Answers (4)

saolof
saolof

Reputation: 1661

The primary benefits of webassembly are completely different from the benefits of the JVM. The JVM works at a higher level of abstraction, does garbage collection and imposes many other specific ways of doing things, and is strongly aimed towards a specific language even if it can host other languages.

Webassembly on the other hand works at a lower level of abstraction and runs the applications more or less unchanged, and can be viewed as another compilation target. However, its killer app compared to something like compile-to-C or LLVM which also offers portability via flexible compilation targets, and where the JVM was also lacking, is the fact that it comes with a built-in security model. It was inherently designed for a platform where running untrusted code is a core requirement, and is the first such compilation target to really catch on.

Since a large portion of all new written code now runs in the cloud or in the browser and is inherently untrusted, that is really huge with regards to adoption. The fact that the compiled code inherently has limitations means that you can run many untrusted code WASM-compiled snippets from different users in the same process safely and write things like serverless REST endpoints.

It also means that you can explore new concurrency models, such as Lunatic, that offers multilingual Erlang-process like semantics where synchronous code written in any language can be sandboxed into lightweight processes and run by a preemptive scheduler, which is achievable because of Wasm being inherently sandbox-friendly so that you have strong guarentees with regards to what any piece of wasm code is allowed to do.

Upvotes: 7

Ricardo Jl Rufino
Ricardo Jl Rufino

Reputation: 597

JVM can run:

  • JavaScript
  • Python (Jython)
  • Ruby (JRuby)
  • Groovy
  • Scala
  • C++ (using JNI)

unfortunately the support for java was removed from the browser, because Sun (former maintainer of java), could not provide adequate support.

Just like the Flash ended up losing.

Upvotes: 1

ColinE
ColinE

Reputation: 70160

There are a great many reasons why the JVM was not deemed a suitable runtime in place of WebAssembly ...

  • WebAssembly was designed with delivery-over-HTTP and browser-based in mind. For that reason, it supports streaming compilation - i.e. you can start compiling the code while downloading.
  • WebAssembly was designed to have rapid compilation times (resulting in web pages that load quickly), this is supported by having very simple validation rules compared to Java / JVM languages.
  • WebAssembly was designed with the concept of a 'host' environment, i.e. the browser.
  • WebAssembly was designed to be secure and simple, minimising the overall attack surface.
  • WebAssembly was designed to support a great many languages (C, C++, Rust, ...), whereas the JVM was initially design for a single language, Java.

As a general observation, WebAssembly was designed to support multiple languages on the web. The JVM was designed to support Java on the desktop. It doesn't make either one better than the other in a more general sense.

Finally, the JVM was integrated with the browser (Java Applets), but that didn't work out in the end!

Upvotes: 81

Bumsik Kim
Bumsik Kim

Reputation: 6653

A quote from the High-Level Goals of WebAssembly:

a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;

So their original goal was running C/C++ program in a web browser, not running Java code.

Upvotes: 7

Related Questions