JVM, CLR, innovation and openness

Alex has written an interesting post about the respective futures of the JVM and the CLR. It hooks in with the news this week about Microsoft’s dynamic language runtime (DLR) for .Net, and also the announcement that Silverlight will run on the Mac.

I think it’s clear that Microsoft are innovating faster on the CLR. For example: LINQ is an extremely powerful new feature (based on Haskell monads, I might add); Generics were supported earlier and better in C# than in Java (both flavours were inspired by Haskell’s polymorphic type classes… hmm!); the CLR has better support for multiple languages than the JVM; and now it has the DLR, which is probably two years ahead of the JVM being able to offer anything comparable.

It’s not necessarily the case that Microsoft is smarter than anybody in the Java world. But you can get a lot more done when you don’t have to reach consensus with 20+ other vendors, and when you don’t particularly care about offering backwards compatibility. As the old joke has it, “How many Microsoft programmers does it take to screw in a lightbulb? None, they just redefine darkness as the standard.” Now that’s agility! By contrast, innovation in Java moves at a glacial pace because of the JCP and because Sun obsesses over backwards compatibility almost to a fault.

But while the JVM is not particularly cross-language, the CLR is not particularly cross-platform. Microsoft is still not committed to supporting platforms other than Windows, and probably never will be. Mono, Rotor and Silverlight are at best half-hearted gestures towards cross-platform support. Remember that IE and ActiveX were once released on Mac as well as Windows, with all the same hype that we’re seeing now… where are they now? Is anybody really going to bet their business on trusting Microsoft to continue supporting Silverlight on Mac? Actually, history shows that plenty of businesses will do exactly that, and they will quickly die when Microsoft changes strategy on a whim, again. Besides, support for just two operating systems falls a long way short of being “cross-platform”. Windows and Mac OS may cover 98% of the world’s desktops, but how many Windows or Mac machines do you see in server rooms? That world is dominated by Linux, Solaris and other UNIX variants. While Mono runs on those platforms, it has nowhere near the maturity and stability of either the JVM or the CLR.

This is one reason why I will not develop for .Net, much as I would like to play with LINQ and so on: it’s effectively a desktop-only framework. On the server side, we still need to run on JVMs.

As a result of this dichotomy, many companies have chosen to go with a strategy of .Net on the desktop and Java on the server. One can certainly see how this might be attractive, especially for companies that are 100% Windows on the desktop, but I think it’s profoundly misguided. For one thing, there is the technical problem of communication between the tiers — at the moment this means Web Services, which are slow and complex. Much bigger than the technical problem though is the human communication problem. It is simply impossible to hire developers who are strong in both Java and .Net. People like that exist, but they are rare, so the companies that choose this strategy have to create separate teams responsible for the two tiers. Those two teams hate each other, naturally. The Java guys bitch about the .NET guys and vice versa, especially when deadlines are missed, which is a fact of life in IT. “It’s not our fault we slipped by 6 months. Those Java guys don’t know what the hell they’re doing! Did you know they have to catch every exception??”

I think that code portability across the desktop and server tiers is very important, so why not use Java? Unfortunately Java has a bad rep on the desktop because it spent many years cursed with terrible performance and hideous GUIs. It seems that too many people were burned by their early experiences of Java to believe that those problems just don’t exist any more, but it’s true, they don’t. The JVM is blazingly fast now, almost as fast as native code. For GUIs, we have Eclipse RCP which is a great framework built on a sane GUI library, SWT. Even Swing sucks a lot less these days than it used to. Eclipse RCP hasn’t made a big splash yet in rich internet applications or in the kind of widely downloaded consumer apps that get reviewed in magazines, but it is rapidly colonizing the landscape for internal corporate applications, particularly in banks, which is the vertical I work in.

There’s another reason why I won’t develop for .Net in the short term: I use a Mac. Sure, Silverlight now runs on Mac, but does Visual Studio? Of course not. In fact, not only do I have to do my development on Windows, but I also have to PAY for the IDE! I have to give money to Microsoft for the privilege of enriching their ecosystem? Has Ballmer forgotten that it’s all about “developers developers developers developers…”? Java has two great, free IDEs, Eclipse and NetBeans (of which I prefer the former). .Net has zero. I simply cannot fathom why Visual Studio is not free — and I’m not talking about some cut-down “Express” edition, I mean the fully featured product. This is such an obvious way to draw huge numbers of developers to .Net. Why is Microsoft now about the only ISV in the world that still treats an IDE as a direct source of revenue?

So the JVM may not be the most innovative kid on the block any more, but it will still be the first choice for a large number of developers, simply because we can see that Microsoft is still playing the same old lock-in game they have always played. Microsoft has previous, and they cannot be trusted with something this important. Neither can Sun, of course. Sun is just another big corporation that ultimately only cares about its shareholders, and it would absolutely play the same game Microsoft does if it were in a similar position. That’s why Java really needed to be open-sourced: in the event that Sun turns evil, a fork of Java can live on under a different name. The CLR may get ever more advanced, but at least we know we can bet our businesses on the JVM.

I do wonder if that’s the solution in the end. Once the Hotspot JVM is open sourced, then anybody can use it as the basis for a new platform, as long as they keep it under GPL. It won’t be Java any more — Sun continue to guard that trademark as jealously as they ever have — but maybe it will be better. First order of business would be to cut the bundled libraries right down down to the bone, and finally remove all those deprecated methods still hanging around since Java 1.0. Second would be to go ahead and implement invokedynamic and also find a way to do proper tail calls. Third would be… well, I have a few ideas, but that’s for another blog post.

In the meantime, Java developers who value their long-term careers should be keeping an eye on what’s happening over in the .Net world. At the very least, we can learn from the experiences of developers as they struggle with new features that we might also be struggling with in a few years time. It also wouldn’t hurt to learn some of the newer languages that now run on the JVM, like Scala and JRuby. They can only get better.

And if you really want to get ahead of the pack, try learning the language that’s been a major source of inspiration for new features in both .Net and Java: Haskell!