The Webmechs Press

I have always felt, despite the competition coming from .Net and the great strides made by the CLR, that Java’s future prospects as a [more or less] general purpose development platform were still pretty good because of its robust ecosystem. However, the acquisition by Oracle, I believe, spells the beginning of the end for this technology.

Sun’s financial troubles meant that selling to Oracle was a proposition very difficult for the former’s shareholders to resist. Oracle’s products have a strategic dependence on Java so it also made a lot of sense for Oracle to do the acquisition (ownership of MySQL just made the whole package an even sweeter deal.)  However, I don’t see how Oracle’s corporate culture can be compatible with Java’s future as a general development platform.  Oracle is focused as a database company and will most certainly drive Java’s development in directions that mainly benefit the Oracle product ecosystem. This can’t help but be to the detriment of the Java platform’s abilities in areas that don’t directly have to do with these ends.  Many have blogged about the exodus of Sun’s top architects post-Oracle. This, to me, just paints a pretty clear picture of the overall trend.

It’s going to be a long time before Java completely fades away, and it is going to remain entrenched in the “enterprise” sector, but as a platform for all-purpose development, Java has been losing appeal for sometime now and I think this is the final nail in its coffin.

This  clears the way for Adobe’s Flash/Flex and .NET to duke it out in the desktop space. Nibbling at their heels (more like slithering up their feet already), are Apple’s iPhone/iPad OS and Android. Android developers can take heart in the fact that Android is only Java in the slightest sense such that Oracle owning the standard will barely matter to them. But of course, at the same time, Android is so barely Java that the ecosystem of the latter only has the slightest intersection with and of  benefit to Android. If a technology like Clojure for the CLR  eventually overtakes the maturity of Clojure for the JVM, I’d consider the prediction - and the fate of Java’s relevance to general computing - sealed.

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