Java’s Da Vinci Machine … and other platforms

After having read about the “Da Vinci Machine”,

http://www.infoworld.com/article/08/01/31/davinci-machine_1.html
http://openjdk.java.net/projects/mlvm/

it struck me that Sun/the Java people have finally seen the wisdom of supporting other languages (esp. dynamic ones) on the JVM and have decided to play catch up with the CLR. The closest CLR analog to the Da Vinci Machine would be .NET’s DLR (dynamic language runtime) which got started much earlier. While Java is clearly entrenched and has a lot of momentum behind it, I think that right now the .NET CLR’s design is the one to beat and has had the benefit of being designed from the ground up rather than being retrofitted. Moreover, while such new JVM enhancements cater to dynamic languages, it does not necessarily mean that they address the issue of inter-language operability.

As you know, in the CLR, components written in different languages can call each other very easily and it is quite clear that a lot of design attention has been made by the CLR designers to making this work cleanly from the start.

Could we expect to see languages besides Javascript/Actionscript running on top of AVM2 in the near future? As Flash is actually a far more widely deployed runtime than J2SE, this would be a very welcome and interesting development.


We see today that the OS wars have taken an interesting twist. The former clear winner – Windows – is facing stiff competition on frontiers beyond the desktop, such as mobile. On the server end, what gains Windows NT/Server had earlier made over a fragmented Unix opposition it now cedes to Linux. Because no single OS can stake a total claim over all the various hardware incarnations we have today, the battleground has instead shifted to runtimes. From where I’m standing, it is starting to look like a 3-way fight between:

A. .Net/CLR – MS .NET, Mono, Silverlight, etc…
B. Java – JVM, Google Android, JavaFx, etc…
C. Flash – Flex, AVM2/Tamarin, …

I have come to appreciate A. for its well-defined API choices. For 3D, You can use OpenGL if you want to do cross platform graphics or DirectX if you only intend to run under Windows. For client UIs, WinForms/Gtk is available cross-platform, whereas you can use the [presumably] more advanced WPF for Windows-exclusive clients. And of course, you’ve got Silverlight/Moonlight for browser hosted RIAs under Windows, Linux or OS X.

B. on the other hand is composed of a mishmash of balkanized, bastardized standards. These have sprung around Java due to Sun’s lukewarm leadership efforts and less than forthright licensing tactics and strategy. They compete directly with each other instead of offering clear differentiating strengths. It is Eclipse vs. Swing, Android/Dalvik vs. J2ME, JavaFX vs. Processing, etc… But, on the other hand, is such competition merely an indicator of a healthy, thriving ecosystem?

With Java, there certainly is *more* stuff – technologies, standards, APIs, frameworks – numerically speaking, built on top of it than for .NET, although the latter is catching up and with quality ones too (e.g. F#, IronPython, LINQ…)

C. is the least confusing runtime platform since you only get one language choice – Actionscript – and essentially a single API framework and another advantage is that Flash deployment is far more ubiquitous than either .NET or Java. One thing to note though regarding Flash is that it targets only half of the equation – client development – leaving you to deploy whatever server side technology you choose.

Licensing-wise, all three are roughly comparable with a mix of open and closed source components.

Since all 3 platforms will – ultimately, is the expectation – run more or less equally well under Windows, OS X, Linux and BSD, developers* now have the freedom to not worry about which OS they target. But… they now have to choose which runtime platform to target!

*with the exception of primitives who still insist on using C/C++ and the respective OS-specific APIs such as Win32 and POSIX/Unix


Leave a Reply

Your email address will not be published. Required fields are marked *