What are the disadvantages of targeting the JVM instead of x86?

Question

I'm developing a new language. My initial target was to compile to native x86 for the Windows platform, but now I am in doubt.

I've seen some new languages target the JVM (most notable Scala and Clojure). Ofcourse it's not possible to port every language easily to the JVM; to do so may lead to small changes to the language and it's design.

After posing this question, I even doubted more about this decision. I now know some "pro" JVM arguments. The original question was: is targetting the JVM a good idea, when creating a compiler for a new language?

Updated the question: What are the disadvantages of targeting the JVM instead of x86 on Windows?

Answer 1

If you create a language for the JVM, you have also the great advantage that a huge library is at your feet, which can be readily used from within your language. This is most likely not the case if you compile for x86. I assume you won't make it possible to include e.g. C-headers in your language without having a C parser.

For this reason Scala, Groovy and others are a such a success.

At the current stage of development of the JVM, and with the new enhancement for supporting scripting languages, I would just target the JVM, because odds are your language will be executed faster then with every runtime library you could ever create for yourself.

Answer 2

You should only target the JVM if you're happy to have the runtime part of your code totally dependent on third party code and requiring your users to install such, and, the JVM will provide substantial features that you can't reasonably develop yourself or ask people to extend for this purpose (e.g. OS headers in C++), and, you're happy with the JNI as your interface to native code (and thus, other managed code like .NET).

Ultimately, it totally depends on the resources available to you and how you pictured language interop. If you're going to use the JVM to provide a lot of features, and you're happy for the interop to be awful, then use it. Else, I think you should reconsider.

Answer 3

You may want to look at targeting the LLVM instead of the JVM. The LLVM can be used to target a number of architectures, including x86.

There's more to portability than simple CPU support, but the LLVM can help a lot and still give you native code, if you like.

Answer 4

Targeting the JVM is a pretty tried and tested approach. The fact that Clojure, Scala, JRuby and many other languages have done so successfully should give you some reassurance.

My view overall is that the JVM is probably the best target at the moment for new/experimental languages, particularly if you hope to achieve cross platform capability while taking advantage of a truly fantastic JIT compiler and a wealth of very powerful libraries.

Having said that, the main disadvantages you may encounter targeting the JVM are in my opinion as follows:

• Lack of tail recursion support at the bytecode level. There are ways around this (e.g. see Clojure's "recur" special form) but it is annoying for some language implementations, particularly functional languages. Will probably eventually be fixed in future versions of Java.

• Slightly obvious, but you need a JVM installed on your client. Usually not a problem nowadays, but there are still cases where this can be tricky.

• Primitives (int, long, float etc.) in Java behave differently from the rest of the object system. Again you can work around this but it is some extra hassle for language implementers.

Some potentially useful/interesting links:

• ASM bytecode analysis and manipulation framework. This is a great tool, I believe it is what what Clojure uses under the hood.

• Clojure source code