Why do so many insist on dragging the JVM into new applications?

For example, I'm running into developers and architects who are scared to death of Rails apps, but love the idea of writing new Grails apps.

From what I've seen, there is a LOT of resource overhead that goes into using the JVM to support languages such as Groovy, JRuby and Jython instead of straight Ruby or Python.

Ruby and Python can both be interpreted on just about any OS, so I don't see any "write once run anywhere" advantage... why bring the hulking JVM along with you?

From stackoverflow

• Java is a much, much more mature platform, with a lot of existing class libraries that could be "dropped in" and used, than, say, Ruby or Python (or even Perl, for that matter). So for people who like using existing code, rather than writing everything themselves, Java is a huge win.

  For example, recently I've been looking for something like JAXB for Python or Ruby. In the end, I ended up using JRuby just because I haven't found any mature, widely-used XML-binding libraries.

  Jegschemesch : On the other hand, the relatively immaturity of Jython and JRuby somewhat defeat the confidence of mind you get from the JVM. Also, the general consensus seems to suggest that the canonical Ruby could be better, though I've never heard real complaints about CPython (other than complaints about its global lock).

  Chris Jester-Young : Any bits where JRuby/Jython's relative immaturity could cause problems could be remedied by routing those bits to Java-language (or Groovy) code. And you still get to keep the widely-used Java-platform libraries. :-)

  Chuck : I don't disagree with you about this being why people lean towards JVM, but WRT "you get to keep the Java libraries," the same could be said of any other language being extended with C, which also has enormous piles of libraries.

  foljs : No, the same cannot be said. It is a pain in the ass to reuse C libraries from "any other language being extended with C", while its entirely transparent --and easy-- calling Java libraries from JRuby, Jython and Groovy.

  sal : In many cases, JVM languages can make use of a decade of legacy Java code in an organization. Much of it dating from the "great rewrites" of the late 1990s and early 2000s when all the Client/Server apps were ported to Intranets.

• why bring to hulking JVM along with you?

  JVM isn't bloated, nor is it slow. on the contrary, it's a lean, fast, deeply optimized VM. Unfortunately, it's optimized for static OOP languages.

  Still, good compilers targeting JVM do create good performing programs. I don't know about JRuby; but Jython's goal is to be all-around faster than regular C Python, and they're getting close (it's already faster at several important use cases).

  Remember that a good JIT (like those for JVM) can apply some optimizations unavailable on static C compilers, getting faster code from them isn't a pipe dream. Of course, a VM optimized for your language should be faster than a 'not-really-generic' VM like JVM; but there's the maturity issue: JVM has a lot of work done there, while JITs for Ruby and Python aren't anywhere near.

  Unfortunately, there doesn't seem to be any better generic bytecode VM. Microsoft's CLI suffers from similar limitations as JVM (ironPython is much slower and heavier than JPython). The best candidate seems to be LLVM. Does anybody know why isn't there more dynamic languages over LLVM? I've seen a couple of Scheme compilers, but seem to have several problems.

  D.Shawley : They are coming. Check out http://mdevan.nfshost.com/llvm-py/

  Ken : He didn't actually say "bloated" or "slow". He said it takes a lot of resources to maintain these backends. Don't we always say programmer time is the most valuable thing? Is spending many, many programmer-hours for maybe a 2x speedup worth it?

  Ken : LLVM isn't very dynamic. If you want a VM for dynamic languages, Parrot is the bytecode to check out.

  Anton Tykhyy : IronPython &c. isn't slower than Jython because CLI is slower than JVM, but because it's actually dynamic (uses DLR) and not compiled to statically typed IL.

  Javier : @ken: AFAICT, LLVM is a portable and optimizing assembly language, with a lot less assumptions about the language as either JVM or CLI. to be dynamic or not is inmaterial at such a low level. of course, a bytecode designed for dynamic languages, like parrot, would be ideal... wish them well

  Javier : @Anton Tykhyy: that's exactly the problem: both CLI and JVM assume a static language, so either you do a heavy and slow emulation at runtime, or create a complex optimizing compiler that can extract the static parts of your program... and still keep the dynamic info for failback at runtime

  Ken : Javier: that's what I meant by "isn't very dynamic". :-) Any (Turing-complete) VM can run any program, of course.

• The huge advantage of writing code (in any language) for the JVM is that it's usually very easy to tap into the enormous wealth of mature Java libraries out there, if necessary.

  And I don't know where you got this idea of a "hulking" JVM with a huge resource overhead. The JIT tends to produce code that is quite fast, and the core JVM is anything but huge by today's standards. It does tend to have a huge memory footprint when running, but that's because modern machines have a lot of RAM and the GC works best when it has a lot of RAM to play with. If desired, the GC can be fine-tuned to hell and back to be more conservative.

  As someone else put it: "The best thing about Groovy is that I don't have to use Java. The second best thing about Groovy is that I can use Java".

  Wouter Lievens : The memory overhead of the JVM is significiant.

  Michael Borgwardt : Define "significant".

  ConcernedOfTunbridgeWells : I've used OWB's mapping tool and had the process running at about 400MB in core. Also, allocates pretty much everything that isn't a primitive type on the heap and garbage collects it when it feels like. This makes for heavy memory usage and poor cache efficiency.

  Michael Borgwardt : @ConcernedOfTunbridgeWells: modern garbage collectors compact the used parts of the heap, which improves cache efficiency - and as I wrote, the overall memory usage can be tuned a lot.

  ConcernedOfTunbridgeWells : Another overhead with the JVM or CLR is that they (IIRC) don't support stack allocation of objects, so all objects - even those with a life cycle tied to program execution flow - involve dynamic memory allocation and additional cache traffic (plus cache traffic generated by the GC that boots items that might have otherwise remained in cache). I think the main reason that managed code feels slow is that it tends to be much less cache-efficient than optimised C or C++ code.

  Michael Borgwardt : @ConcernedOfTunbridgeWells: The Java 6 JVM can do escape analysis and allocate objects on the stack.

• Groovy is NOT an interpreted language, it is a dynamic language. The groovy compiler produces JVM bytecode that runs inside the JVM just like any other java class. In this sense, groovy is just like java, simply adding syntax to the java language that is meaningful only to developers and not to the JVM.

  Developer productivity, ease and flexibility of syntax make groovy attractive to the java ecosystem - ruby or python would be as attractive if they resulted in java bytecode (see jython).

  Java developers are not really scared of ruby; as a matter of fact many quickly embrace groovy or jython both close to ruby and python. What they don't care about is leaving such an amazing platform (java) for a less performant, less scalable even less used language such as ruby (for all its merits).

  Chris Jester-Young : Jython and new versions of JRuby both compile to bytecode too, so the OP's mention of "interpret" does not mean what you think it means. :-)

  Florin : The question was: Why drag the JVM into new applications? Using jython or jruby would "hulk the jvm along". The question was, how come no ruby when you guys are yet happy with groovy which is syntax-wise kindda the same.

  Chris Jester-Young : Right, I see what you're saying. Thanks for clarifying.

• The big knock on RoR is that it isn't scalable and hard to deploy. By using the Java platform, you can leverage your existing infrastructure.

  grails war
  

  Produces a war file that is easily deployed on Glassfish, Jboss, etc.

  sal : ruby's warble does the same thing for RoR apps. Not a knock on groovy, just that this isn't something unique.

• Ruby and Python can both be interpreted on just about any OS, so I don't see any "write once run anywhere" advantage... why bring the hulking JVM along with you?

  Mostly because you want to take advantage of the HUGE existing ecosystem of Java libraries, APIs and products, which dwarfs anything available for Ruby or Python, especially in the enterprise domain.

  Also, keep in mind that JRuby and Jython are faster in a lot of benchmarks than the regular (C implementations) of the languages, especially Ruby (even Ruby 1.9).

  Having multiple languages targeting the same virtual machine has a lot of benefits, such as leveraging a common infrastructure, code reuse, shared APIs, the ability to use whatever language is conceptually best for you, or for a specific problem domain, etc.

  The same things happens in the .NET space, with multiple languages targeting the CLR. The Parrot (vaporware) VM project also aims to the same thing, and it's a stated goal of the LLVM project too.

• The reason is Hotspot.

  It is an engineering tour de force.

• the other reason not many mentioned is existing infrastructure related to jvm - if you already have a server running java stuff, why not use it instead of bringing in yet another platform (like rails)?

• An assumption that seems to be built into the question is that new projects are greenfield projects. Many organizations have made a huge investment in Java over the last decade+ and require any new project to work within the existing (internal) code ecosystem. As pointed out, there's a huge bonus in all the publicly available Java libraries (whether free/OSS or commercial), but the need to work with existing code and even as a component within an existing system is at least as important (if not more so) to large organizations.

  A lot also comes down to the maturity and capability of the platform, which is to say the JVM and everything that comes with it (the entire Java ecosystem). A few examples off the top of my head:

  • You can plug a remote debugger into a running JVM and get all kinds of information about a running application that is simply impossible with Python, Ruby, etc. Going a step further, there's JMX, a standard way to write code so that objects can be monitored and even tweaked in a live application. Take a look at JConsole and see if you don't drool just a little (despite the ugliness of the interface).

  • Going even further in this direction, there's OSGi, a standard for writing highly modular code that can be deployed, started, stopped, and even upgraded in a live application. With OSGi you break a large application into many smaller "bundles" which can then be maintained (deployed, started/stopped, upgraded) separately. This is a really big deal in large applications, or any applications that need to remain running at all times.

  • The platform has very good support for asynchronous, reliable messaging. You get JMS as a baseline, and many excellent and powerful libraries built on it for doing complicated things with very little code (cf. Apache Camel, ServiceMix, Mule, and many others). This is another feature that's extremely valuable in larger applications or those which must run within a larger code universe.

  • The JVM has real (OS-level) threading, while Python et al. are very limited in this regard (notoriously so). (That being said, shared state concurrency -- threading -- is the wrong approach; cf. Erlang, Alice, Mozart/Oz, etc.)

  • There are numerous JVM choices beyond the standard Sun implementations, like JRockit, IBM's JVM, etc. This is a developing area with other languages -- Python has Jython, Iron Python, even PyPy and Stackless; Ruby has JRuby, Rubinius, and others -- but as good as these are they can't match the maturity found in the various JVM offerings.

  All that being said, I really don't like Java the language and avoid it as much as possible. These days with all the excellent alternative languages for the JVM I don't have to. Groovy gets my vote for its accessibility and tight integration with the platform (and even the language), and because of Grails, which I sometimes like to call "Rails for grownups". I like other JVM languages better, particularly Clojure and Scala, but these aren't as accessible to the average programmer. Scala is popping up a lot lately, though, especially thanks to its high profile use at Twitter, so there's hope for interesting and truly excellent languages making it in larger environments. But that's another topic.

  Kedare : As a JConsole alternative, you have JVisualVM that has a MUCH better GUI.