Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate?
I consider the JVM to be the best part of programming in Java. The JVM is fast, lets you write very portable code, and it gives you a great debugging experience. Plenty of other languages chose to target the JVM, like Scala and Clojure, for its quality.
That's not to say the JVM is perfect. I don't like type erasure for instance (I understand C# has 'better' generics). Nevertheless - and this idea comes up frequently - imagine if browsers ran VM bytecode instead of interpreting JavaScript. The browser would be totally language-independent. You could write in any language that compiles to the browser bytecode, and deploy the precompiled bytecode 'object' files. I mean, it is a great idea in theory, and it's exactly what the JVM has succeeded in doing, except that the JVM does it for operating systems and not browsers.
Of course, this is all a fantasy at this point. There's no possible way browser vendors would ever agree on a standardized virtual machine, much less all implement it (see DartVM).
> Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate?
No, I'm not trolling. I was responding to someone who said that the two non-dead browser plugin technologies were flash and silverlight. Java is notably absent from that list. (Can you even interact with the DOM from a Java applet?)
I agree with you that the JVM is the best part of Java, but that's not saying much IMHO.
Java applets had a lot working against them from a technical and UX perspective: they were insecure, and popped up quite scary warning notices about security that had to be clicked through in order to run the applets. Java was also poorly optimized for consumer-facing applications: JIT startup and warmup time was sufficiently long that they felt more sluggish than HTML/CSS/JS, despite the fact that in the long run the JVM outperforms JS by a significant margin.
In an aside, the JVM has only relatively recently been an effective general-purpose compile target, and it wasn't designed as such. The JVM's failure for frontends doesn't give much indication as to where the pitfalls of targets like PNACL or asm.js might be: it died (deservedly) because of reasons that apply to neither technology — slow startup time and lack of effective sandboxing. Both PNACL and asm.js start quickly, lean on hardware-acceleration in the browser to react smoothly, are designed from the start as compile targets, and are sandboxed to the point where browser vendors don't feel the need to pop up warning boxes that scare off consumers.
I consider the JVM to be the best part of programming in Java. The JVM is fast, lets you write very portable code, and it gives you a great debugging experience. Plenty of other languages chose to target the JVM, like Scala and Clojure, for its quality.
That's not to say the JVM is perfect. I don't like type erasure for instance (I understand C# has 'better' generics). Nevertheless - and this idea comes up frequently - imagine if browsers ran VM bytecode instead of interpreting JavaScript. The browser would be totally language-independent. You could write in any language that compiles to the browser bytecode, and deploy the precompiled bytecode 'object' files. I mean, it is a great idea in theory, and it's exactly what the JVM has succeeded in doing, except that the JVM does it for operating systems and not browsers.
Of course, this is all a fantasy at this point. There's no possible way browser vendors would ever agree on a standardized virtual machine, much less all implement it (see DartVM).