The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore.
All the other browsers killed it as well.
There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something?
I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser.
Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)
I think an important difference is that in the new architecture, there's a separation between WASM and WASI.
That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it.
As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details.
So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.
Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to.
Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications.
Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to.
I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI.
Why does WASI need to exist if Java already exists for the intended uses?
> Why does WASI need to exist if Java already exists for the intended uses?
IMO, the reason is that the market showed that Java never got used like that. I can only speculate on the reasons, but as far as I can tell it comes down to:
1) The sandbox isn't good enough. See my sibling comment -- the separation between WASM and WASI makes a lot of sense, and I don't think Java had that.
2) The fact that you can't port C code to the JVM easily. In fact WASI addresses exactly that -- the API is more like POSIX than a brand "new" bunch of JVM APIs, which makes it easier to port existing native apps (C, C++, Objective C, Rust, etc.)
In other words, there's still a lot more "value" in native code apps than JVM apps. And it's too hard to port native code applications to the JVM.
For example, Photoshop, Illustrator, Word, Excel, etc. were never ported to the JVM. There are actually better analogs in the browser than on the JVM.
I ran windows for 15 years and Linux for 10-15 years. On neither of those platforms have I ever needed a JVM. I used to play online chess in a Java applet, and that's about it. Most common desktop apps avoid dependencies on the JVM. Probably the only reason I could think of installing one is to use Eclipse or IntelliJ.
The browser is the main reason why anybody had a JVM installed in the first place. Without that hook, the JVM becomes much less important on the client. It's still very important on the server.
Java is important and successful, but it empirically did not succeed at some of its design goals. Of course, WASM and WASI may also fail -- that remains to be seen. But to me they look like a good attempt, based on significantly different technical foundations.
1) There's a large difference between a compiler that exists and an efficient one. The JVM is designed for Java and not C, which makes efficient compilation hard / impossible. Graal as mentioned is an extremely unusual research technique that may make it feasible.
Basically people underestimate how hard it is to make a VM that can run multiple languages. JRuby and Jython work, but it takes heroic efforts.
2) The interface to the OS, as mentioned. You can maybe run some algorithms like image processing, but try running the native sqlite code on the JVM, or something even hairier involving networking. It's not straightforward.
WASI provides something that's closer to what C programs expect than what Java provides. As I said, the market voted with its feet. All the friction adds up. If you try hacking on that compiler or manually porting code, you'll probably get a sense of why that is.
The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does.
This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages.
The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.
True, I forgot about Graal. IIUC though that's somewhat different from what WebAssembly has done- Graal doesn't define any sort of stable compiler target for C, or produce JVM bytecode from C, but instead (via Truffle) JITs C source or LLVM IR via partial evaluation, right?
That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associated environment/binding system are a portable way to encode C binaries, with significant benefits over JVM bytecode- that's probably the comparison I should have made.
> You can run all those languages on top of the JVM!
Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.
Webassembly came from asm.js, which came from Emscripten. These 3 are a lineage of the same c compilation model targeting a JS Uint8Array as the c heap. Emscripten was published a long time ago, probably 10 years? So, JVM has byte arrays too...
To the extent that their object and memory models match the JVM's, you might say they were. To the extent that they don't, their JVM implementations wind up with warts and inconsistencies.
(But this is pedantry, you clearly know what I meant.)
Well, the second paragraph in the article gives you the answer:
> Why: Developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines.
It allows you to use the same code both inside and outside of the browser. For example, Figma might use it, they already have a web app and a regular app, both using WebAssembly, so WASI would perhaps simplify their code or allow them to add more native integration to their app.
Making a product that's a slight variation of an existing product is often enough to gain significant market share. For example, was Chrome needed when there was Firefox? Was Figma or Adobe XD needed when there was Sketch? Is Rollup or Parcel needed when there is Webpack and Gulp? This could go forever. I mean, should Java be the only universal deployment platform?
There are open source and non-Oracle Java virtual machines you can buy support from if Oracle isn't your cup of tea.
It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)
Google's was not using Oracle's virtual machine, and their attorneys were not frauds, but they've been tied up in litigation for most of a decade and are facing potentially ten billion dollars in penalties.
Signed types and a proper cross language target. There is very little technical difference between the two, esp now that GraalVM has shipped. WASM is now the portable executable standard.
So you're saying the JVM wasn't good enough so they had to make a better one? Why does the HN crowd constantly compare WASM with the "obsolete" JVM, when even the creator admits that it is not adequate?
JVM could have been WASM but they made some unfortunate design decisions. They started as a target only for Java, GC, signed types. WASM started from the bottom, floats and ints (signed and unsigned) with plans to add GC, threads etc later.
It isn’t that the JVM is bad, it is that it isn’t the universal compilation target that WASM is.
Remember folks getting excited about LLVMIR, Bitcode? WASM is this but with a clean sandbox and minimal tractable semantics.
The JVM is awesome, esp with Graalvm and Truffle. WASM is the next evolutionary step.
Java still exists and is a valid deployment platform.
Why is WebAssembly outside of the browser needed?