63

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.

ColinE
  • 68,894
  • 15
  • 164
  • 232
Jawahar
  • 4,775
  • 1
  • 24
  • 47
  • 9
    The JVM certainly could be integrated into web browsers, there is no technical impossibility. Although, bytecode running in a JVM is always slower than native machine compiled code, I assume the main reason is probably political (don't want to put a lot of Java/Oracle in the web which should stay neutral/free?) Interesting question anyway :) – sjahan Sep 27 '19 at 09:52
  • 2
    It seems the performance of WASM isn't actually that (native) good, so I'd tend to really think about political stuff :) – sjahan Sep 27 '19 at 09:54
  • 6
    The time will come and Java will compile to WASM as well. – jayarjo Sep 29 '19 at 06:34
  • @jayarjo Except for trademark-related reasons, I guess we won't be allowed to call it Java :/ – Mark K Cowan May 13 '20 at 21:33
  • 1
    Web is supposed to be open. Oracle is the least open tech company ever. – Pacerier Jun 07 '20 at 16:52
  • JavaScript is significantly faster than WASM at certain tasks related to image/video processing. You can see for yourself here: https://takahirox.github.io/WebAssembly-benchmark/ – Tobias Bergkvist Sep 24 '21 at 14:43
  • @Pacerier exactly .. alongside with nVidia maybe xD Both are quite scumbags, that trying to vendorlock whole world in their $hit, 0% cooperation, 100% agresivity, lawsuits etc. Flash was cool technology but made by Adobe .. same story. – JsonKody Aug 03 '23 at 12:57

4 Answers4

79

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!

ColinE
  • 68,894
  • 15
  • 164
  • 232
  • 1
    Well, in some way, people already thought of this issue and a) created a feature request for GraalVM to run WebAssembly code and b) maybe some 'simply' implements a JVM in WebAssembly. – Stefan Rother-Stübs Nov 13 '19 at 10:52
  • @StefanRother-Stübs I assume that you were talking about GraalWasm: https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-in-graalvm-25cd0400a7f2 – gouessej Jan 15 '20 at 09:32
  • Nonetheless, there are several compilers that [translate JVM bytecode to WebAssembly](https://github.com/appcypher/awesome-wasm-langs#java) and [vice-versa](https://github.com/cretz/asmble). – Anderson Green Aug 26 '20 at 21:51
  • 10
    "Finally, the JVM was integrated with the browser (Java Applets), but that didn't work out in the end!" Java enthusiast here: the JVM was used **through a plugin**, but that's not the same as being "integrated with the browser" if you ask me. The fact that it was a separate runtime with it's own update method etc. was one reason for its downfall. They should have created a lightweight / secure VM that could be integrated with the browsers instead of relying on 70 MB downloads when CORBA changed implementation at the same time as a security fix. I'm very much agreeing with the rest of the post! – Maarten Bodewes May 02 '21 at 13:28
  • @MaartenBodewes Can that be done through WASM and SubstrateVM? – Jayadevan Vijayan May 15 '21 at 09:06
  • This is a great summary of all the important design decisions that make wasm more suited to be the new vm of the browser. Well done! – Adam Sandor May 21 '21 at 14:13
  • I find most of these arguments gray: 1) Java/Oak was designed to delivered code over network. That is why it has Classloaders. The hole concept of "distributed agents" was there before Java was named Java. 2) Java and JVM bytecode were designed for rapid compiling and lower memory usage. Each class file can be compiled indepentently, and there is no notion of compilation unit etc. 3) JVM was designed with notion of Host enviroment and proper secure embedding. That is point of 'VM' in JVM. 4) I would argue that - at compute spec level - JVM is even simpler than WASM. – Talijanac Sep 01 '23 at 11:42
  • The only real diference between JVM and WASM is implementation part. WASM is created for broader languages by providing compute model which is less abstract view of platform. For example there is no notion multithreading in WASM. Insted it exposes host capabilities. Same as C. While JVM has memory / threading model which is same on all hosts no matter what.. Proper implementation of JVM would be perfectly fine within web browers. It is mostly about politics and desired direction of web authors why it isn't there. – Talijanac Sep 01 '23 at 11:46
6

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.

Bumsik Kim
  • 5,853
  • 3
  • 23
  • 39
5

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.

saolof
  • 1,097
  • 1
  • 15
  • 12
0

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.

Ricardo Jl Rufino
  • 549
  • 5
  • 10