Sun's MLVM aka "The Da Vinci Machine" caters for the needs of many compiled and interpreted languages. Since Sun already gathered a lot of expertise with the JVM it's going to be a sure hit. Reliability and performance will be equally excellent without a doubt. And of course it will also run Java.
Yesterday during his keynote at Sun Tech Days James Gosling announced that they hired Ted Leung (a long-time Python developer from OSAF) and Frank Wierzbicki (the lead implementer of the Jython project). Both are going to work full-time on Jython - an implementation of Python written in 100% pure Java.
Sun also got JRuby creators Charles Nutter and Thomas Enebo and and a bunch of other smart guys. We'll certainly see quick progress from now on.
Piggybacking on the countless years of research is a huge benefit for many languages. Especially the new ones can gain a lot here. But the biggest benefit is something different: a unified scripting interface. With that I mean scripting through VM invocation and not JSR 223 (Scripting for the Java Platform) or the like. (Something like JSR 223 can be used further down the pipeline tho.)
Many bigger applications such as Inkscape support scripting to some degree. If different languages are supported, different interpreters need to be shipped. (Inkscape for example only ships a Python interpreter, but there are also a few extensions written in Perl.) But it doesn't stop there: the interpreters need to be found/identified/invoked, using an unsupported language isn't be easy, performance varies a lot, and interpreters may behave differently.
All of this adds complexity and is the source of many bugs and glitches - multiplied with the number of platforms you support. With a single VM the amount of glue would be reduced to the absolute minimum. The VM could be also kept alive until the host application terminates in order to remove startup time. Additionally, caching, just-in-time/hotspot compilation, and cutting the edge garbage collection can speed up things quite a bit.
In Inkscape's case the recent push of Python is more than welcome. Most extensions are written in Python, which means the transition over to the MLVM (if it ever happens) will be a lot easier.
Comments
Java Market Share
Also not to forget this will allow the Java VM to become even more widespread as any app using one of the above scripting languages can bundle and install it on the computer running the application. (+Java Kernel?)
Hum...
Well, bundled VMs are usually private VMs. I.e. it resides in a subdirectory of the application and won't be registered (file associations and the like) with the operating system.
The main reason for doing so is the elimination of a possible source of incompatibility.
Using the public (=user installed) VM isn't that problematic anymore. But it might be not worth the (possible) trouble in Inkscape's case, since Inkscape is already over 25mb in size.
Bundling a Kernel thingy which is installed as pubilc VM might be a possible option as well. If no VM is found or if the installed VM is too old, install it - otherwise skip this part. However, there are still tools missing for creating your own kernel thingy. E.g. if you want to add a specific set of libraries to the package. Requiring a net connection as soon as the user uses extension x might be a bit annoying.
So, there are still a few open questions, but 6uN (Java 6 update N - aka the Kernel VM) is certainly an interesting bit of technology. It just isn't quite ready for prime time yet. Things should look different in a few months tho.
edit: Oh I forgot... another advantage of a private VM is the simpler invocation. You know where it is; there won't be a reason to do any OS specific queries beforehand.
Post new comment