Why are so many new languages written for the Java VM? [closed]

Question

Why don't they write a new VM for a new language?

That one is easy:

• writing a good VM is hard
• writing a fast VM is hard
• making a VM run under multiple architectures is hard
• existing libraries work with existing VMs
• existing tools (debuggers, profilers, compilers, ...) work with existing VMs
• getting people to install a new VM is hard
• instant interoperability with other languages targeting the same VM
• existing VMs have been thoroughly tested in production

Performance and Libraries

• The JVM is one of the world's most heavily-optimized pieces of software.
• To take advantage of the huge array of Java class libraries.
• The fact that interaction between Java and non-Java languages inside the JVM works.

The JVM is rock solid and works from the tiniest Java SmartCard (ok, a tiny VM ;) to the biggest clustered super-computers you can imagine.

Because it is rock solid, there are entire countries where people have:

• a Java SmartCard in their wallet as either their national ID card or as their medical care system card (or both)
• a cellphone that has a JVM (or a Dalvik VM, which is basically Google's rebranded version of the Java VM). Heck, the iPhone has an ARM CPU optimized to run Java bytecode (but for business reason Apple decided not to offer Java on the iPhone/iPad).
• a BluRay player that of course has Java (because it's part of the BluRay spec).

I'm developping commercial software in Java: we're selling on Windows and on OS X but we're all developping on Linux. And it just works. And it works on Solaris too, etc. And that's because we're targetting the JVM: goodbye portability issue. As long as the platform has a VM, the software shall work.

Then I can't believe anyone mentioned it yet: it is a very good start from a security point of view.

The Java VM is, by design, immune to buffer overrun/overflow. This is huge. This is actually huger than most people realize.

The only "Java" buffer overflow that I remember on Linux (that prompted me to upgrade due to security concern) was actually a buffer overflow leading to arbitrary code execution in... a C written lib (zlib if I remember correctly, back in the days Java on Linux was still defaulting to that lib).

Sure, for webapps buffer overrun/overflow leading to arbitrary code execution are not the most important vector of attack anymore (now that XSS and SQL injection have stolen the show). But in all the other cases buffer overrun/overflow are the source of most security issues.

The JVM is immune to that.

In addition to that thanks to its design it's easy to plug various tools on it like profilers and debuggers.

It is a very solid and secure (when used correctly) technology. That is why it is so widely used by both tech-savvy (Java is huge at Google, from GMail to their Android to GWT etc.) and tech-not-that-savvy companies.

It is actually arguable that Java's success comes from the JVM and that "Java the VM" is much more important than "Java the language".

The JVM is the biggest "language" success story of these last 20 years. And it is deserved. And it is here to stay :)

• has seen 15 years of refinement, performance improvements etc.
• is free and open source
• runs on a wide variety of platforms
• supports multiple languages on a single VM
• the main language (Java) is one of the most widespread languages out there so Java + JVM is a relatively safe entry point
• reasonably secure and robust

Because somebody else has already taken the trouble to make sure it runs well on every major platform.

If you write your own VM, you have to write one for Linux/Unix/BSD, one for Mac, and one for Windows, and you have to support the VM on all those platforms as well as supporting your language compiler and runtime libraries. If you use the Java VM, the first part is taken care of for you by Oracle, IBM and Apple.

Because with almost 20 years of effort the Java VM is

• portable
• enough efficient, not as C or C++ but with a good performance (considering it's still a vm)
• easy to integrate with
• estensively supported with APIs or libraries

I mean, if i would plan to release a new language why shouldn't I use the JVM? Ok, there are others vms (llvm, parrot) but the JVM is estensively supported, known, and tested.

And it works also quite good! The lack of invokeDynamic will be solved with the relase of Java7 so better than this..