A frequent topic of discussion these days is whether, and to what extent, the Java Virtual Machine is suited for languages other than Java, and in particular “dynamic” languages like Ruby. Sun says yes, others disagree–so how do we settle it?
One line of argument says that the JVM was developed first and foremost to host Java, and that it is ill-suited for languages other than Java. A similar argument is applied against Microsoft’s CLR design, and C#: people say you can run any language on the CLR, as long as it looks like C#.
It’s a fact that many, many languages have actually been ported to, rewritten for, or written for the JVM. Some of these are experimental languages or ports, and others are used in production–for example, “scripting” languages like BeanShell. But what we don’t know, and can’t easily evaluate, is whether those languages are constrained by the JVM’s design, or not–would they be better off in another virtual machine? Can we contemplate a more universal, welcoming virtual machine which would give us more freedom in language design and implementation choices?
This is how I understand the question, but I think it’s addressing the wrong point. The JVM is a good choice because it’s behavior and internal characteristics are well-defined, and there are several–not just one–implementations to choose from, both commercial and open-source. The availability of multiple versions (and the fact that the same byte code does actually work with them, unchanged) is proof that the spec is tight enough to provide a reliable basis for developing a language in the JVM. Moreover, some JVM implementations (Sun, IBM, BEA) have proved themselves in the most demanding production environments, with high degree of availability and solid performance. Last, the JVM has proven itself to be highly portable across machine and operating system architectures. Those are good reasons to choose the JVM, at this point in time, to host new languages. Eventually, much of this will apply to the CLR as well.
My point is that in discussing this, we should all be more clear about the strengths and limitations of the JVM, and that we can derive those from the specification. What we have in hand is a VM that is already working, production-quality, high (or reasonably high) performance, and which has been ported to a number of CPUs and operating systems. Start from that as a basis. Then say–given what the specification says is available to me–what is possible to do, language-wise? The approach some people seem to take is–I have a wish list for a language, why is the JVM so limited, and why doesn’t it let me easily implement feature X?
I’m not saying we should exclude, out of hand, any other virtual machines, VM designs, etc. Obviously the JVM will be replaced with something better at some point, in terms of wide deployment and market acceptance. It seems, for example, that decisions made early on in the design of the JVM limit its applicability or usefulness for certain language features, like dynamic code replacement (hot swappable code), lack of unsigned ints, etc. It has limitations, great, let’s admit that and move on–what I’m arguing here is that there are good reasons to choose the JVM (or the CLR, if you will) as hosts for new languages, until such time as competing approaches to VMs mature and prove to be really competitive alternatives to the current mainstream.
(Orignally posted on this JRoller blog entry)