Why do we need other JVM languages

Question

I see here that there are a load of languages aside from Java that run on the JVM. I\'m a bit confused about the whole concept of other languages running in the JVM. So:

Answer 1

Because the JSR process is rendering Java more and more dead: http://www.infoq.com/news/2009/01/java7-updated

It's a shame that even essential and long known additions like Closures are not added just because the members cannot agree on an implementation.

Answer 2

The .NET languages are more for show than actual usefulness. Each language has been so butchered, that they're all C# with a new face.

There are a variety of reasons to provide alternative languages for the Java VM:

• The JVM is multiplatform. Any language ported to the JVM gets that as a free bonus.
• There is quite a bit of legacy code out there. Antiquated engines like ColdFusion perform better while offering customers the ability to slowly phase their applications from the legacy solution to the modern solution.
• Certain forms of scripting are better suited to rapid development. JavaFX, for example, is designed with rapid Graphical development in mind. In this way it competes with engines like DarkBasic. (Processing is another player in this space.)
• Scripting environments can offer control. For example, an application may wish to expose a VBA-like environment to the user without exposing the underlying Java APIs. Using an engine like Rhino can provide an environment that supports quick and dirty coding in a carefully controlled sandbox.
• Interpreted scripts mean that there's no need to recompile anything. No need to recompile translates into a more dynamic environment. e.g. Despite OpenOffice's use of Java as a "scripting language", Java sucks for that use. The user has to go through all kinds of recompile/reload gyrations that are unnecessary in a dynamic scripting environment like Javascript.
• Which brings me to another point. Scripting engines can be more easily stopped and reloaded without stopping and reloading the entire JVM. This increases the utility of the scripting language as the environment can be reset at any time.

Answer 3

What the JVM can do is defined by the JVM's bytecode (what you find in .class files) rather than the source language. So changing the high level source code language isn't going to have a substantial impact on the available functionality.

As for what is required to write a compiler for the JVM, all you really need to do is generate correct bytecode / .class files. How you write/compile code with an alternate compiler sort of depends on the compiler in question, but once the compiler outputs .class files, running them is no different than running the .class files generated by javac.

Answer 4

The advantage for these other languages is that they get relatively easy access to lots of java libraries.

The advantage for Java people varies depending on language -- each has a story tell Java coders about what they do better. Some will stress how they can be used to add dynamic scripting to JVM-based apps, others will just talk about how their language is easier to use, has a better syntax, or so forth.

What's required are the same things to write any other language compiler: parsing to an AST, then transforming that to instructions for the target architecture (byte code) and storing it in the right format (.class files).

From the users' perspective, you just write code and run the compiler binaries, and out comes .class files you can mix in with those your java compiler produces.

Answer 5

You need other languages on the JVM for the same reason you need multiple programming languages in general: Different languages are better as solving different problems ... static typing vs. dynamic typing, strict vs. lazy ... Declarative, Imperative, Object Oriented ... etc.

In general, writing a "compiler" for another language to run on the JVM (or on the .Net CLR) is essentially a matter of compiling that language into java bytecode (or in the case of .Net, IL) instead of to assembly/machine language.

That said, a lot of the extra languages that are being written for JVM aren't compiled, but rather interpreted scripting languages...

Answer 6

The reason is that the JVM platform offers a lot of advantages.

• Giant number of libraries
• Broader degree of platform implementations
• Mature frameworks
• Legacy code that's already part of your infrastructure

The languages Sun is trying to support with their Scripting spec (e.g. Python, Ruby) are up and comers largely due to their perceived productivity enhancements. Running Jython allows you to, in theory, be more productive, and leverage the capabilities of Python to solve a problem more suited to Python, but still be able to integrate, on a runtime level, with your existing codebase. The classic implementations of Python and Ruby effect the same ability for C libraries.

Additionally, it's often easier to express some things in a dynamic language than in Java. If this is the case, you can go the other way; consume Python/Ruby libraries from Java.

There's a performance hit, but many are willing to accept that in exchange for a less verbose, clearer codebase.