Why do many insist on dragging and dropping JVMs into new applications?

Question

For example, I come across developers and architects who annoy Rails applications to death but love the idea of ​​creating new Grails applications.

From what I saw, there are many resources that use the JVM to support languages ​​like Groovy, JRuby, and Jython instead of direct Ruby or Python.

Ruby and Python can be interpreted for almost any OS, so I don’t see the benefits of “write sometime anywhere” ... why bring a clumsy JVM with you?

Answer 1

Java is a much more mature platform, with many existing class libraries that can be "dropped" and used than, say, Ruby or Python (or even Perl, for that matter). Therefore, for people who like to use existing code, instead of writing everything themselves, Java is a huge victory.

For example, recently I was looking for something like JAXB for Python or Ruby. In the end, I ended up using JRuby just because I didn't find mature, widely used XML binding libraries.

Answer 2

The huge advantage of writing code (in any language) for the JVM is that it is usually very easy to use the huge wealth of mature Java libraries out there if necessary.

And I don’t know where you got this idea of ​​“clumsy” JVMs with huge overheads. JIT tends to release code that is pretty fast, and the core JVM is nothing more than today's standards. It tends to have a huge amount of memory at work, but this is because modern machines have a lot of RAM, and the GC works best when it has a lot of RAM. If desired, GC can be tuned to hell and vice versa to be more conservative.

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

Answer 3

The assumption, which is apparently related to the issue, is that new projects are projects of a new level . Many organizations have made huge investments in Java over the last decade + and have demanded that any new project work within the existing (internal) ecosystem of code. As already noted, there is a huge bonus in all public Java libraries (whether free / OSS or commercial), but the need to work with existing code and even as a component in the existing system is at least important (if not more so) for large organizations.

Also, a lot depends on the maturity and capabilities of the platform, namely the JVM and everything connected with it (the entire Java ecosystem). A few examples from the top of the head:

• You can connect the remote debugger to the running JVM and get all the information about the running application, which is simply not possible with Python, Ruby, etc. The next step is JMX , the standard way to write code so that objects can be tracked and even configured in a real application. Take a look at JConsole and see if you drool a lot (despite the ugliness of the interface).

• Going even further in this direction, OSGi is a standard for writing highly modular code that can be deployed, launched, stopped, and even updated in a real application. With OSGi, you break up a large application into many small “packages” that can then be supported (deploy, start, stop, update) separately. This is really a big deal in large applications, or in any applications that should work constantly.

• The platform has very good support for asynchronous and reliable messaging. You get JMS as a baseline, and many excellent and powerful libraries are built on it to perform complex tasks with very small code (cf. Apache Camel , ServiceMix , Mule and many others). This is another feature that is extremely important in larger applications or those that should work in a larger code universe.

• The JVM has real (OS-level) stream processing, while Python et al. in this respect are very limited (as is known). (In this case, the split state of concurrency - threading is the wrong approach, cf. Erlang , Alice , Mozart / Oz , etc.)

• There are many JVM options outside of standard Sun implementations such as JRockit , IBM JVM, etc. This is a growing field with other languages ​​- Python has Jython, Iron Python, even PyPy and Stackless; Ruby has JRuby, Rubinius and others - but how good they are, they cannot match the maturity found in various JVM offerings.

All that has been said, I really don't like Java in the language and avoid it as much as possible. These days with all the excellent alternate languages ​​for the JVM I don't need. Groovy gets my vote for its accessibility and tight integration with the platform (and even the language), and because of the Grails, which I sometimes call "Rails for adults." I like other JVM languages, especially Clojure and Scala , but they are not so accessible to the average programmer. However, Scala has appeared recently, especially due to its high profile.

Answer 4

Why compress the JVM with you?

JVM does not swell or slow down. on the contrary, it is a thin, fast, deeply optimized virtual machine. Unfortunately, it is optimized for static OOP languages.

However, good JVM-targeted compilers create good executable programs. I do not know about JRuby; but Jython's goal is to be faster than regular C Python, and they get closer (this is faster in a few important use cases).

Remember that a good JIT (for example, for the JVM) can apply some optimizations that are not available for static C compilers, getting faster code from them is not a dream. Of course, a virtual machine optimized for your language should be faster than a not-so-general VM, such as a JVM; but there is a maturity problem: the JVM does a lot of work there, while the JITs for Ruby and Python are not nearby.

Unfortunately, there seems to be no better universal bytecode virtual machine. The Microsoft CLI suffers from similar limitations, such as the JVM (ironPython is much slower and heavier than JPython). The best candidate seems to be LLVM. Does anyone know why there are no more dynamic languages ​​on LLVM? I saw a couple of Scheme compilers, but it seems to have a few problems.

Answer 5

Groovy is NOT an interpreted language, it is a dynamic language. The groovy compiler generates JVM bytecode that runs inside the JVM just like any other java class. In this sense, groovy is similar to java, just adding syntax to the Java language, which makes sense only for developers, not for the JVM.

The productivity, simplicity and flexibility of the developer syntax make w21 attractive to the java ecosystem - ruby ​​or python would be just as attractive if they led to java bytecode (see jython).

Java developers are not really afraid of ruby; in fact, many quickly span groovy or jython, both close to ruby ​​and python. What they do not need is to leave such an amazing platform (java) for a less productive, less scalable and less used language such as ruby ​​(for all its advantages).

Answer 6

The big knock on RoR is that it does not scale and cannot be deployed. Using the Java platform, you can use the existing infrastructure.

grails war 

Creates a war file that can be easily deployed to Glassfish, Jboss, etc.

Answer 7

Ruby and Python can be interpreted for almost any OS, so I don’t see any “write once in a row” anywhere ... why the clumsy JVM with you?

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

Also, keep in mind that JRuby and Jython are faster in many tests than regular (C-implementations) languages, especially Ruby (even Ruby 1.9).

Having several languages ​​oriented to the same virtual machine has many advantages, such as using a common infrastructure, code reuse, common APIs, the ability to use any language for you, or for a specific problem domain, etc. .

The same thing happens in the .NET space, several languages intended for the CLR. The Parrot (steamware) VM project is also aimed at the same thing, and this is the stated goal of LLVM .

Answer 8

The reason is Hotspot.

This is an engineering tour.

Answer 9

Another reason that many did not mention is the existing jvm-related infrastructure - if you already have a server working with java materials, why not use it instead of bringing another platform (for example, rails)?

Answer 10

I came across this, and was also puzzled by this, and here is my theory.

Enterprise software is full of Java programmers. As programmers of all stripes, many Java programmers are convinced that their language is the fastest, most flexible and easiest to use - they are not too familiar with other languages, but they are convinced that those who practice them should be savages and barbarians, because any enlightened person, of course, will use Java.

These people created extensive, complex Java infrastructures: rube-goldberg framework machines and automatically generated code filled with Byzantine inheritance structures and very, very large XML files.

So, when someone comes and says: “Hey, let me use the language interpreted by C! It is fast and has neat libraries and much faster for creating scripts and prototypes!” The java guy is first, like "Do I have to run a makefile to configure this? QUEL HORREUR!" Then the reality of the need to deploy and host on servers running the OS and dated versions of Tomcat, and does not begin to install anything else.

"Hey, I know! There is a Java version of this interpreted language! It can break on the speed lane on the bridge at rush hour, and sometimes it lights up, but I can get Tomcat to run it. I don’t need to get my hands dirty by learning stuff other than java and I can train him in the existing infrastructure! Win! "

So, is this the “right” reason for choosing a java scripting language implementation? Probably no. Depends on your definition of "right." But I suspect that this is the reason they are chosen more often than snobs like me who would like to believe.