The JVM as a plugin is almost dead on desktop already, due to very bad past malware vector experiences.
Anyway, plugins are dead code walking, not only because of security worries, but because "mobile" in full trumps desktop, and the de-facto "no plugins on mobile" OS-set standard.
Plugins alas are still "facultative not obligate" on the desktop, so browsers support them. Even on desktop, their days are numbered (see Chrome killing NPAPI plugin support; see also Shumway).
The JVM isn't going to be integrated directly (i.e., not as a plugin) into browsers, either.
For all its virtues on the server side, and I'm thinking of multiple JVMs here going back to the CLDC VM that Macromedia tried to license from Sun for Flash (rejected: they did Tamarin instead), "the" JVM is nowhere near a clean fit on the client side.
This leaves the already-obligate-not-facultative JS VMs, which are evolving fairly rapidly due to browser competition, serving both hand-coded and compile-to-JS workloads.
All as predicted! I think Dave Herman first spoke about this at Web Rebels in 2012, and a bunch of us have laid bets well before then, including on HN. Yeah, I've been hard on PNaCl as a would-be better plugin for safe native code, not due to the tech itself as because of the opportunity cost.
Now that it's 2015, everyone seems to be on convergent paths toward some kind of LLVM-compiled, cross-browser, safe-native intermediate code that's evolved from JS (starting from asm.js, but not restricted to the current subset, e.g., shared memory threads could be added only to the intermediate code and its runtime).
Such a "WebAsm" or js.bin format would then co-evolve with JS until source code download goes away -- if JS source download ever does (I'm skeptical, but given enough time, it could happen).
Lots of risk still, but this remains by far the shortest-distance evolutionary path from where we are.
The JVM is indeed great in many ways. The main issues with it today, I would say, are
* Patent and copyright issues - the lawsuit with Google is still going on, last I heard.
* There used to be serious technical issues with startup speed. People saw websites with Java applets and saw how slow they were to load. If that hasn't been fixed, it's a serious problem, as websites do need to load fast, unlike typical Java applications.
edit:
* A big use case is compiled C++ code. I am aware of lots of languages compiling to the JVM, but I actually don't think I heard of C and C++. Is there such an option? If such an option doesn't exist, or exists but runs more slowly than asm.js currently does (which is pretty close to native already), it would be a problem.
Could Java applets modify the DOM? Were they nicely integrated with the Browser interface? Did they come bundled within the browser for easier installation and upgrades by their users?
Sure there's some parallels, but don't pretend industry ditched Java applets due to ignorance. Javascript in the browser, for 99% of web applications, provides a much better user experience. The developer experience we could argue here, but I'd say nowadays developing client side JS (or TypeScript, CoffeeScript, Haxe etc.) isn't that bad. The tooling is great and there's if anything, too many frameworks to choose from (competition is good!).
The same arguments apply for Flash, really. Flash integrated slightly better with browsers at the expense of being a resource hog.
As for why not the Java VM, my guess is that the browsers are staggeringly enormous piles of C++ code and trying to integrate a Java VM into it would probably be insanely difficult, and anything other than pure 100% integration, too slow to use. It is probably literally easier to continue with the already-integrated JS VM and improve it up to JVM-esque quality than to try to graft the JVM into the browsers that exist today.
Or somebody would have already have tried since nothing would have prevented JS from already running on the JVM, if that were feasible; asm.js is actually independent of this question when it comes down to it.
The JVM does not run in the browser. Its windows can run physically "in" the browser window, inasmuch as it would appear that the Java app was "in" the browser, but the Java app itself was a "plugin", and was a separate OS process. That's not the right kind of "in".
The JVM has never run in the same process as the browser, to the best of my knowledge, with the exception of the ill-fated "HotJava" browser: http://en.wikipedia.org/wiki/HotJava which ran Java applets "in" the browser by virtue of being written in Java, instead of C++. At the time this was too sluggish for general use, though.
So allow me to repeat myself: We can't run the JVM in the browser right now. The impedance mismatch between the JVM and the C++ world are just too great to have sufficient performance right now. All the current browsers are enormous piles of C++ code. There is no way to "just" integrate a JVM directly into them, and no bridge between the two is going to have enough performance for the demands we're putting on browsers. It doesn't matter how awesome Java may or may not be when the browsers aren't in Java. It's not an option today, short of replicating Sun's feat and rewriting your own browser in Java. But the only thing stopping you from doing that is the sheer size of the task, rather than any technical problem. (But make no mistake, it is an enormous undertaking now to write an engine capable of replacing any of the existing ones for even a single well-chosen use case.)
> You know tons of language already compile and run on the JVM, right?
Yes. So?
> And you know the JVM ran in the browser almost 20 years ago,
And it did such a good job that everyone has been prefering java applets to html/js/flash for those 20 years.
Oh, actually, they didn't. In fact, with few exceptions, they have been rejected by users for most of those 20 years. The implementation was horrible. I don't know if it's better today - maybe it is for some Windows browsers. But no browser on my Mac or Linux supports it without an external install -- and last time I actually used it (~2 years ago), it still took forever to start applets.
It might have worked if the execution was acceptable; it's not impossible - flash had reasonable execution which lead to widespread adoption that is still nontrivial despite a big part of the web - that of mobile - made it unusable. And yet, 18 years later (I'm up-to-date as of 2 years ago), Java applets are still a mess.
So, the bottom line is: who cares the JVM ran in the browser?
The applet user experience is horrible, you're right. It's pathetic that this hasn't been fixed.
Instead, we're developing apps on a platform intended for delivering documents, and targeting code to a "bytecode" (asm.js) built on a half-baked language originally intended for doing form validation, pop-up ads, and animating dancing bears.
Java and the JVM form a 3/4 baked language environment originally designed to run on washing machines, freezers and TV-top sets - that after 20 years can't even get applets and GUI properly.
See how easy it is?
Yes, I completely dislike JavaScript. I also completely dislike Java. But both are here to stay, regardless of their (lack of) merits compared to some ideals. Java missed the browser bus because it was horrible, and JavaScript drives the bus now because it was there.
Hah. I totally agree. I personally dislike both Java and Javascript, also. Javascript was born brain damaged. Java had a chance, but it jumped the shark sometime in the early 2000's when J2EE took off.
There is a tendency for history to repeat itself in programming, since, as Alan Kay put it, programming is "not quite a field" as it lacks a proper sense of its own history. So going by this, I predict that VM vulnerabilities are going to creep into the JS ecosystem, put there in the name of optimization, much like the "Use After Free" vulnerabilities in the JVM for Android.
We're reinventing the wheel because the Java plugin didn't reach critical mass. There's never been a time that you could require Java in a web app and expect a trouble free experience for your users.
Perhaps the browser/OS vendors and Oracle could have worked together to make this happen, but they didn't, and the world moved on.
