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

views:

1350

answers:

+21 Q:

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

There are more and more programming languages (Scala, Clojure,...) coming out that are made for the Java VM and are therefore compatible with the Java Byte-Code.

I'm beginning to ask myself: Why the Java VM?

What makes it so powerful or popular that there are new programming languages, which seem gaining popularity too, created for it?
Why don't they write a new VM for a new language?

+4 A:

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.

Paul Tomblin 2010-03-19 14:23:02

+2 A:

Obvious reasons:

There is a massive existing class library
There are multiple VM implementations, which are widely deployed.
These languages are more similar semantically to Java than you might think.

Matthew Flaschen 2010-03-19 14:23:03

+3 A:

Second question first: Why reinvent the wheel? There are multiple implementations of the Java VM, including highly-optimized ones, and there's at least one available for darned near any platform out there.

First question second: There is a huge amount of third party library and tool support for code compiled to Java bytecode and run on the VM. When you create a new language, one big issue is that you have to create everything that people can use with it, or make it compatible with something else (like linking to existing static C libraries, or .Net, or COM, or the Java VM). The Java VM's open specification (erm, so far), deep history, and broad applicability make it a nice target for new languages.

T.J. Crowder 2010-03-19 14:23:41

+13 A:

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

Tomislav Nakic-Alfirevic 2010-03-19 14:23:57

+40 A:

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

Joachim Sauer 2010-03-19 14:23:57

In addition, getting people to install a VM is hard. Most people already have a Java VM installed.

David Thornley 2010-03-19 14:26:03

And you get instant interoperability with other languages targeting the same VM.

Daniel Earwicker 2010-03-19 14:37:19

Feel free to add anything, it's community wiki for a reason ;-) I try to keep it VM-agnostic, because most reasons apply to using any big, existing VM, not just the Java VM.

Joachim Sauer 2010-03-19 14:40:49

+4 A:

What makes it so powerful or popular that there are new programming languages, which seem gaining popularity too, created for it?

It's free & open, mature (stable, complete), and the surrounding ecosystem is huge.

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

Writing a VM as good as the JVM is hard. JVM's spec and its implementations have been refined for well over a decade by the finest minds in the industry.

Joonas Pulakka 2010-03-19 14:24:11

The finest minds in the industry? :-)

Ken 2010-03-19 19:00:01

Well it was a bit weirdly said :-) There are several JVM implementations, but for instance Sun's HotSpot is work of people such as Cliff Click. And of course the JVM spec matters a lot; it's a result of Java Community Process, a huge number of experts. Somehow it works, even though designed by a committee :-)

Joonas Pulakka 2010-03-20 07:57:02

+4 A:

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..

Jack 2010-03-19 14:25:00

+19 A:

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.

Bruno Rothgiesser 2010-03-19 14:28:13

"The JVM is one of the world's most heavily-optimized pieces of software." <-- Except for startup time :P

Billy ONeal 2010-03-19 19:04:53

@Bruno Rothgiesser: +1... The fact that on quite some benchmarks algorithms thanks to JIT "compilers" can beat C is a testimony to how good and mature the JVMs are now. See my answer for another reason too: the JVM is also amazingly secure (no buffer overrun/overflow).

Webinator 2010-03-19 19:18:24

@BillyONeal: yup, but a) this is constantly getting addressed (you can already set up class sharing .jsa type archive to speed up startup time if there's already a JVM running) and getting better and better with each release (just like Java now can *beat* C in quite some benchmarks) and b) this is really only a matter if you're writing command line utils like "grep" or "wc" that you want to chain. On the server side the point is moot and, honestly, on the Desktop side too (we're selling commercial software written in Java). But, agreed, when I need a quick command line util I write in in Bash.

Webinator 2010-03-19 19:22:41

(just like Java now can beat C in quite some benchmarks) <-- Usually because Java's string implementation is much better than C's. It can be annoying as a user however waiting for the JVM to load itself -- it's nothing to do with what happens for a specific program, it has to do with loading the JVM itself from disk. For server-side it doesn't matter, I agree -- but I've been frustrated by some Java applications before for this reason.

Billy ONeal 2010-03-19 19:52:28

If the itch is strong enough somebody will write a java-based shell that loads programs under its own classloader. (That is, the shell has its classloader and it creates a child classloader used to load the application itself.) You'll still have some startup time but won't have to launch a new JVM each time. Non-java apps would just be run under a System.exec().I think somebody had played with this a while back - jsh (for java shell) perhaps?Hint: if somebody is inspired to do this, support groovy as your scripting language!

bgiles 2010-03-19 21:49:50

+3 A:

Why don't you get started?

fastcodejava 2010-03-19 14:29:47

Because its not a Microsoft technology. As others have mentioned, there are a lot of great reasons to use the JVM, but I think it would be slightly less popular if Microsoft's CLR was as free, as portable, and as open.

mikerobi 2010-03-19 18:39:27

@mikerobi: but of course there's a contradiction in what you're writing: Microsoft is and has always been about "vendor lock-in", so they will not make something *"free, portable and open without fineprints"*. Then there's the performances and security issue: the JVM has an outstanding security track record (look at my answer), you hardly can say that about MS technology. Then the "big guys" (cellphone world, TV/Media) didn't want to let happen to their world what happened to the personal computer world: that's why BluRay players specs mandates Java, not the CLR.

Webinator 2010-03-19 19:09:45

This begs the question, since the CLR is similar enough in spirit to the JVM that one could simply ask, "okay, why would people (Iron(Python|Ruby)/Boo/(Unity|Linden)Script) write new languages for the CLR rather than implement their own VMs" The same phenomenon occurs.

Jimmy 2010-03-22 14:58:13

@WizardOf Odds, there is no contradiction, you are pretty naive if you think that openness and platform support don't factor into decisions to adopt JAVA over .net. and I don't get why I got the down votes. @Jimmy, people target the CLR for many of the same resons mentioned here for opting for the JVM.

mikerobi 2010-03-22 15:23:05

+12 A:

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 :)

Webinator 2010-03-19 18:47:08

Longpoke 2010-06-05 01:03:00

@Longpoke: This is exactly as I wrote... Look at those vulnerabilities: GIF and PNG C-written lib buffer overruns/overflows etc., like the only one ever affecting me I remember (the zlib one I mentioned in my +11 votes response). The fact is: you ain't written Java code that will trigger a buffer overrun/overflow and hence the attacker has a very hard time, because he cannot attack your code anymore by crafting it's input, he has to find a way, through your Java program, to attack one of the C-written part of the JVM. Good luck with the practicality of that ;)

Webinator 2010-06-07 16:20:49

ansaurus

tags:

views:

answers:

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

related questions