
Ask HN: Why hasn't JVM become the defacto implementation for dynamic languages? - bryanalves
The JVM has been around for a while now.  It's stable, mature, and fast.  Lots of languages have started to get ported over to the JVM, and things like Scala exist to make the JVM a great computing platform.<p>With recent dynamic language implementations on the JVM meeting or surpassing performance of the "native" VMs, why hasn't there been a move to have the JVM become the default implementation?<p>Jython is a great example. It's fast -- faster than CPython in a lot of cases, and it doesn't  have the GIL.  And it gets access to the full Java environment if it wants it, presumably including things like Clojure, JRuby, Scala, etc. where appropriate.<p>This seems like a win/win to me, yet there is almost no traction in this direction.  I can think of a couple of reasons why this might be:<p>1. I'm wrong and Jython isn't actually any faster.<p>Even if it isn't faster, the better environment should make up for this.<p>2. Integration with Java land isn't that much of a benefit.<p>Having access to all of this stuff -- but not being forced to use it -- seems great to me.  There's no real downside and lots of potential upside, including increased market penetration in enterprise environments.<p>3. The JVM won't benefit from dozens to hundreds of programmers from python/ruby/etc applying what they've learned in their respective languages to it.<p>Maybe this is a case of too many cooks in the kitchen.  Linux seems to do well with the "shittons of developers working simultaneously" method of doing things, why can't the JVM?<p>Even if the language developers don't work on the JVM at all, so what? See points 1 and 2.<p>4. Lagging behind by a few versions (Jython is at what, 2.5.x?) is a bigger deal than I'm imagining.<p>This could be made up for within a year or 2 if languages committed to the JVM as their default implementation.<p>5. Non-perfect compatibility breaking lots of stuff<p>This is a major concern, right?  It's not like Python3 isn't doing the same thing right now, or seemingly every version of Ruby doing the same thing.  Oh wait, they do.<p>Maybe the JVM isn't the right vm to standardize on; maybe LLVM would be more appropriate.  I don't know.  What I do know is that it seems silly for a bunch of language designers to all be having a big case of NIH and writing their own vms and bytecode interpreters.<p>Thoughts?
======
SoftwareMaven
One of the really big issues with the JVM (outside of the "It's Java" or
"Scary Oracle" stuff) is startup time. Many dynamic languages came into being
to scratch an itch for scripting. In those cases, being able to start up
quickly is important.

Clojure, Groovy, Scala, and others have shown ground-up dynamic languages on
the JVM can be very good and very successful. But that doesn't mean there
isn't value outside of the JVM, too.

Once you say "All languages must be on the JVM", you significantly limit
innovation, since you are tied to what Oracle decides is worthwhile. For
example, it probably makes sense for there to be no tail-call optimization in
the JVM, but that is pretty important for a very large class of languages.

~~~
runT1ME
Scala is pretty much the opposite of a dynamic language...

------
jfasi
I think the reason is both technical and social.

The JVM has a very hard time integrating existing C code and extensions. For
instance, in the case of python, Jython lacks the ability to take advantage of
the significant number of modules written in C.

Consider what this means for performance. Imagine a pure python module that
attempts to import a C submodule for performance, and falls back on on the
pure python implementation specifically to allow it to run on non-CPython
implementations. json is an example of such a module.

This module was likely engineered and architected with C module optimization
in mind. I'd assert that in most cases the pure python module is a crutch to
allow a CPython-targeting module to run on other implementations.

This leads into the social reason. Community takes a long time to build and
using the JVM for dynamic languages is a relatively new trend. The JVM is a
very mature, well-optimied technology for static languages. It is only now
that dynamic languages are starting to gain traction on it.

------
icebraining
There's a recent blog post[1] by one of the CPython core devs. He talks about
Pypy, not Jython, but I think it applies too:

 _Personally, I think the status quo in this space is in a pretty good place,
with python-dev and CPython handling the evolution of the language
specification itself, as well as providing an implementation that will work
reasonably well on almost any platform with a C compiler (and preferably some
level of POSIX compliance), while the PyPy crew focus on providing a fast,
customisable implementation for the major platforms without getting distracted
by arguments about possible new language features._

[1]: [http://www.boredomandlaziness.org/2011/08/of-python-and-
road...](http://www.boredomandlaziness.org/2011/08/of-python-and-road-maps-or-
lack-thereof.html)

------
vorg
When Oracle bought Sun, Java lost its mojo. Sure, Java still has many more
installs, but who would trust Oracle with it medium- to long-term. Microsoft
was clearly evil when Java was born, and in the late 1990's. But Microsoft
turned, created C#, and has slowly nurtured it so it's now better than Java in
many ways, e.g without Java's rotten type erasure, snappier in Visual Studio
than JVM-anything in Eclipse, with the dynamic keyword, ... Now everyone knows
Oracle is more evil than Microsoft, and the JVM is just one of many platforms,
alongside .NET, javascript ..., we can develop to.

------
teyc
Dynamic languages were not very well served until invokedynamic came about.

If you have a careful look at the Java bytecode, every non virtual function
call is resolved at compile time. However, for dynamic languages, function
resolution is at run time. And at the moment, it can only be done via
reflection, and not amenable to JIT optimizations. However, this is all
changing, and if Java could shed some of their static classes (which affect
start up time), it has a good chance going forward.

------
jp
Sun was a supercomputer company. Java is the alternative to IBM operating
system VM's running on mainframes. Nobody has that kind of hardware just lying
around. Java was designed to run on $1000 SCSI hard-drives and 32Gb of RAM.
The focus is on standardization, scalability, portability, buzzwords and
expensive catering.

The guy that made the Chrome Javascript VM sat with a laptop in a small house
in the Danish countryside. Because the focus was on normal everyday hardware.
And guess who that was ? A former Sun Java VM programmer. So the "just use
Chrome" developer demographic is sort of unintentionally ironic when they,
well, open their mouths. Why do they think Chrome is so memory hungry anyway
:P Well, the problem is actually the same problem that you have in other UI
frameworks where event listeners and DOM references never gets released from
the UI side. And there are some strange issues with anonymous functions and
closures, but I do not know enough about that to comment.

Java is fine, but Javascript does not need to be Java. Apple just screwed up
the LiveConnect bridge in Safari just to piss us off.. transition us all to a
better state of mind. Or maybe that was Oracle, I have no clue anymore. The
guy that worked on Jython probably felt very alone doing all the work and
JRuby is only here because of desperation from Sun. And Scala is the solution
for people who never finish anything. So maybe I should.. oh shiny..

[http://www.businessweek.com/globalbiz/content/nov2008/gb2008...](http://www.businessweek.com/globalbiz/content/nov2008/gb20081112_082312.htm)
[http://labs.teppefall.com/2011/08/why_not_use_java_and_invok...](http://labs.teppefall.com/2011/08/why_not_use_java_and_invokedynamic.html)

~~~
daniel_solano
> Java was designed to run on $1000 SCSI hard-drives and 32Gb of RAM.

This is plain wrong. Java was originally developed as a language for embedded
devices, not servers. Later, it was targeted for the web (remember applets?).

These days Java may be best known for being "enterprise", but that is hardly
its origin.

------
mtogo
The JVM is mostly nonfree, controlled by Oracle, and isn't easily or readily
available on systems other than Windows. I cringe whenever i see an
application of some sort that relies on the JVM, as i know there's a rather
small chance of that application working properly.

In theory it's great, but in practice it sucks.

~~~
amorphid
The JVM is available on Linux and Mac OS X, too.

~~~
mtogo
Sure it's available, but it's error-prone to install, often an old version,
and generally breaks all over the place.

~~~
Aloha
There are other implementations too, like IBM J9 and GNU Kaffe. I remember
using J9 in place of Sun Java when I was a desktop Linux user.

~~~
chc
Oracle has demonstrated a certain eagerness to sue alternative
implementations, so I'm not sure those really get around the issue

------
Joakal
If JVM is purported to be so good in terms of performance, why not just create
a JOS too? The VMs is only as fast as the OS from my basic understanding. It
would mean an easy port of applications in JOS to other JVMs too.

