34

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?

Seki
  • 11,135
  • 7
  • 46
  • 70
sdudo
  • 1
  • 2
  • 4
  • 2
    Who is "they" in the last question? – matt b Mar 19 '10 at 14:22
  • 8
    Since it's a subjective question, I think this should be a community wiki. – Tarka Mar 19 '10 at 14:24
  • I imagine it's because it's been around for a while so it's well known, and well tested. It's backed and supported by large companies (IBM, Sun, Oracle (which I guess now includes Sun), etc...) so that probably helps too. All of these mean it's probably going to be around for a while. Should be a community Wiki question. – FrustratedWithFormsDesigner Mar 19 '10 at 14:24
  • 3
    Slokun, I disagree it's a subjective question: "popularity" in this context is a function of a wide variety of technical and other properties: making these explicit (the point of the question) allows people to make better decisions related to software development. – Tomislav Nakic-Alfirevic Mar 19 '10 at 14:31
  • 1
    matt b: Should be clear if you read the first paragraph. – sdudo Mar 19 '10 at 14:41
  • Maybe the question should be rephrased to ask why so many new languages build on top of existing VMs (or on the Java VM specifically). – Joachim Sauer Mar 19 '10 at 14:41
  • @Slokun: community wiki means the author wants to surrender ownership of their content to the community, it is *not* a synonym for "subjective questions". – Juliet Mar 19 '10 at 18:47
  • Why is the Windows operating system so popular? –  Mar 19 '10 at 18:56
  • @Juliet Ah, still kinda new here, thought it was meant more for discussion topics, where there's a number of possible answers, none which could really be deemed "correct" – Tarka Mar 19 '10 at 18:58
  • 2
    @fuzzy lollipop: because IBM made a terribly bad deal back in the days? And because since then Microsoft has been officially recognized as a monopoly that did actually abuse its monopoly to keep and try to extend that monopoly to other areas? Java and the JVM came out of nowhere and won an insanely huge userbase and big companies' hearts (Google, FedEx, Walmart, every single bank in the world, etc.) based on technical merits? In other words, precisely for the inverse reason... – SyntaxT3rr0r Mar 19 '10 at 19:28
  • 3
    Why don't dune buggy hobbyists design and build a new engine for every new kind of buggy? – dmckee --- ex-moderator kitten Mar 21 '10 at 06:17

10 Answers10

54

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
Rafał Dowgird
  • 43,216
  • 11
  • 77
  • 90
Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
26

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.
b.roth
  • 9,421
  • 8
  • 37
  • 50
  • 3
    "The JVM is one of the world's most heavily-optimized pieces of software." <-- Except for startup time :P – Billy ONeal Mar 19 '10 at 19:04
  • 4
    @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). – SyntaxT3rr0r Mar 19 '10 at 19:18
  • 2
    @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. – SyntaxT3rr0r Mar 19 '10 at 19:22
  • (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 Mar 19 '10 at 19:52
  • 1
    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 Mar 19 '10 at 21:49
19

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

SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • "The Java VM is, by design, immune to buffer overrun/overflow. This is huge. This is actually huger than most people realize." **Thank** you. An O/S full of BoF's can never be secure. Actually, there have been quite a bit of vulnerabilities in JRE implementations (http://osvdb.org/search?search[vuln_title]=jre&search[text_type]=titles), but if someone was to make a pure hardware JVM and do rigorous testing as is done at Intel, it should be fine. In any case, it's already on the order of a magnitude more secure to write things in Java than C :) – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Jun 05 '10 at 01:03
  • @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 ;) – SyntaxT3rr0r Jun 07 '10 at 16:20
15
  • 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
  • 10,017
  • 5
  • 38
  • 51
5

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
  • 179,021
  • 58
  • 319
  • 408
5

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
  • 36,252
  • 29
  • 106
  • 169
  • The finest minds in the industry? :-) – Ken Mar 19 '10 at 19:00
  • 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 Mar 20 '10 at 07:57
5

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
  • 131,802
  • 30
  • 241
  • 343
4

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
  • 1,031,962
  • 187
  • 1,923
  • 1,875
4

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
  • 20,527
  • 5
  • 46
  • 42
  • 6
    @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. – SyntaxT3rr0r Mar 19 '10 at 19:09
  • 2
    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 Mar 22 '10 at 14:58
  • 1
    @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 Mar 22 '10 at 15:23
3

Obvious reasons:

  1. There is a massive existing class library
  2. There are multiple VM implementations, which are widely deployed.
  3. These languages are more similar semantically to Java than you might think.
Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539