Put a Monkey In Your Phone

With all the hoopla surrounding Mono these past few weeks, it can hardly be considered a surprise that according to the Chinese calendar this is the Year of the Monkey. After all, the Monkey is one of the most dynamic signs of the Chinese zodiac, being commonly associated to movement and changes.

And given the way the discussion on opening Java is raging, some sort of change is definetly in the works. It should be pretty obvious to most people at this point that Mono and C# are gaining mindshare, especially because they are riding the .NET juggernaut in a way Microsoft never anticipated.

Better (and considerably more carefree) heads than mine are dissecting this phenomenon at length, ranging from language comparisons to outright (sometimes near-fanatical) advocacy - which, truth be told, lies mostly on the Java side of things. My intent here is not to even the score, just to shed some light on things the way I see them.

I do tend to see them from a Mac OS X standpoint, of course, and the issue of how this affects the Mac and independent developers was just touched on the other day, but this is bigger. Way bigger.

Miguel has had a crucial role in pushing Mono forward in both the desktop and server spaces (you can run ASP.NET code in Apache right now, in case you didn't know, and it looks pretty finished), but most people by now have locked on to the cross-platform potential of the Windows.Forms assembly - which is only natural.

One of the main reasons is that it (Windows.Forms on Mono) makes sense. A lot of sense, especially to people looking to have a real cross-platform framework that they can invest time and resources in without fear of ripping it out five years down the road. The fact you can develop for it in pretty much any language (on any platform) is just icing on the cake.

Because, you see, what real developers want is to "code for the ages" and only have to solve each problem once. But more on that further on.

Why Java Is Struggling

I'm sure to get some flak for this section, so I urge Java advocates to skip it. Believe me, you are not likely to like this bit. And the one after the next is even scarier and more important, so you'd best read that first.

The first thing I ask people who say they know Java is "Which Java?". And I don't mean the Microsoft VM (which is only too often confused with J#), IBM's kit or even HP's (pretty much forgotten) clean-room clone. I mean the utter mess that the JDKs became shortly after they hit 1.1.

Of Shards And Middleware

Java (no matter what the purists say) is not a single language. It has evolved piecemeal and in odd bursts as Sun tried to plug a few holes in it, and it's looking pretty scarred from all the tussles.

The most obvious scars are the way its class frameworks are twisted this way and that to cover the holes in Sun's platform strategy, with interesting features being split from the main trunk for re-use in mostly the same way you'd try to assemble a crystal jar's shards to form an eggcup.

The result is, of course, a mess to deploy in any sort of stable enterprise environment. And guess what, one thing corporate IT managers value is stability, and not just where it relates to uptime.

Inflated Expectations

It did Java no end of harm to have developers (usually paid for and trained on ridiculously bloated dot-com era salaries) rejiggle their server deployments with every new release. That only became worse when inconsistent performance across both platforms and releases started happening, not to mention the difficulty of tuning anything related to Java and the insane hardware requirements for both developers and servers.

Mind you, Java is very impressive when properly deployed. Things like Tomcat and Cocoon show what it's capable of in a server-side environment (even if the WAR deployment model can be somewhat of a mess), and at this point there is (still) little else to turn to if, say, your tastes cater to heavy-duty multi-target (i.e., mobile) content rendering.

Swinging From The Trees - And Falling

Of course, the client side is different. I have no doubt that Java has failed as a client-side language in anything but mobile phones (more on that later).

That was mostly due to the Microsoft-Sun VM tantrums - Microsoft pretty much killed the applet scene when it refused to evolve its VM to be JDK 1.1 compliant, and Sun completely missed the fact that people don't want to jump through hoops to download the JRE. And I'm not even going to mention the hassle involved in installing the JRE on Linux - it's just not easy (or light) enough for people to do it every six months or so.

As to standalone applications, I personally loathe Swing and blame it for most of Java's problems on the desktop, but since that would warrant a full blown usability rant on its own and I want to get to the point, I'll end my Java rant with the following paragraph:

I like Java a lot. But I hate the fact that it is not (by any stretch of the imagination) a truly portable runtime, that it has no decent GUI bindings, and that the language itself is a moving target - in short, it's just not a skill worth investing my time in.

You see, it's all about permanence - I want my skills and my code to be usable ten years from now, in mostly the same way I can still code in C/C++ (yeah, I'm that old), but without the portability hassles.

This is something a newbie fresh out of college will have a hard time wrapping his/her mind around (after all, they are conditioned into believing themselves to be hotshots with all the answers and the latest tech at their fingertips), but it's pretty obvious that one of the biggest technological (and economical) mistakes people have been labouring in this past decade is believing that technology can be replaced (or worse, assuming it will be replaced) in a couple of years.

Guess what, it can't. There is a lot of old tech in service, mostly because we didn't learn from our mistakes and design it properly the first time around. People are just not tuned to the fact that, despite all the latest and greatest inventions, the three-tier model (presentation/business logic/database storage) is all most applications require - provided you know what you're doing and avoid getting yourself trapped inside architectural patterns.

And it just doesn't make sense to completely rebuild the most expensive part of it all (which is invariably business logic) in whatever new language comes along a couple of years down the road.

That said, Mono and .NET seem a far better investment - .NET will be pushed out to the gazillions of machines Microsoft will control during the next century, and it has shown itself to be (largely thanks to C#) a better Java than Java - and, thanks to Miguel and the others, not just on paper.

But the real frontier is not the desktop anymore. Or the PDA. No, it's the smartphone, or whatever PDAs and phones evolve to.

So here's my suggestion to Novell (and the reason I started writing this in the first place): grab the opportunity to outflank Microsoft in the mobile space and implement a J2ME replacement - as a Mono framework on top of an optimized runtime.

In short, make Mono run on mobile phones.

(The Java advocates, having finally reached this bit, shriek in horror and faint.)

Yes, J2ME is the mobile platform standard. It took Sun years to garner enough attention from phone manufacturers and developers to the point where most mobile phones support it (or what passes for a compatible subset).

But (like I myself have verified from time to time) it suffers from the same problems as its bigger relations: wildly varying implementations, a veritable maze of different device profiles, and a dearth of truly open and cross-platform tools (just try developing for J2ME on a Mac, or even Linux - most SDKs are only distributed as Windows installers, and rely on specific Windows-only tools).

Maybe Mono (or a subset of it) could become a viable alternative in a few years. After all, both the C# language and the runtime specs seem adequate to the task.

The Bard Enters

Let's assume it is doable, and let's (for the sake of argument) call it Shakespeare, after the "infinite monkeys on an infinite number of typewriters" parable.

With current phones' CPU capabilities (anything that can run Java and play Xmas carols in surround sound can surely run Mono) it looks downright doable. But let's review the main issues with turning Shakespeare into reality:

• Fostering industry adoption (oooh, tricky...)
• Defining a standard framework (without the crippling mistakes of J2ME).
• Defining a decent set of device profiles/capabilities (without shutting the door on features like controlling phone functions, handling streaming media and complex interfaces).
• Insuring Shakespeare (the mobile runtime) has room to evolve without compromising backwards compatibility.
• Developing (or adapting) interchangeable tools and debugging environments like emulators (the one field where both Sun and handset manufacturers failed miserably).

At this point, anti-Microsoft groupies will be firing up their e-mail client to rant about how Microsoft will try to put .NET on phones, "embrace and extend" any mobile runtimes that come along, etc., etc.

Of course the likely popularity of .NET is liable to raise issues with handset manufacturers, who are unwilling to bet on anything that brings them closer to Microsoft. But commitment is, as always, a relative thing. Nokia, for instance, is still sitting on the fence on J2ME - on one hand it provides "enhanced" (i.e. proprietary) MIDP profiles, and on the other it backs "native" Symbian development on the Series 60.

And SonyEricsson tried to push Mophun for ages - to no avail, it seems.

But guess what? All of that doesn't matter. Why? Because Mono can do something nobody expected: It can even the playing field. It can provide Microsoft-like ubiquity and ease of development, but a lot more open (and hence malleable). And I don't think any handset manufacturer likes paying Sun license fees for the Java runtime, no matter how much it helps to sell their phones (I used to have figures for Sun's Java division, but I lost my copy of their annual report).

Sure, Microsoft can create (and license) their own mobile .NET runtime (and believe me, it's coming - they wouldn't miss looking that far into the future). It already has the best .NET tools in the market. But it is not guaranteed to have success - because, if Shakespeare becomes a reality, Microsoft will be forced to compete with anyone that builds and licenses a Shakespeare runtime. And the same goes for development tools, emulators, training, i.e., the works.

To Go Beyond Bananas

Of course, all of this might well come to nothing. Novell is still trying to become relevant again on the desktop space, and they lack the well-oiled Java marketing machine that helped Sun put its VM on nearly every modern mobile phone.

And it is quite a bit early in the game. But it sure as hell looks doable, even if we're a bit short on typewriters at the moment.