Wouldn’t it be great if you could write software that ran on Windows and non-Windows systems? Imagine if there was a programming language and a run-time system that supported object oriented programming and automatic garbage collection so that you could write software quickly and not have to worry about pesky memory pointer problems. Imagine, too, if that language came with an assortment of run-time libraries that let you write a variety of applications without having to call system-specific funtions. Wouldn’t it be great, too, if the language came accompanied by a first-class development environment with fast, incremental, compilation, a good editor and, most importantly, a great debugger?

Doesn’t exist. Sorry.

Java’s not it. Java promises to be this but it’s not. Here’s what’s wrong with it:

1. Sun, and the Java community in general, wants to be so operating system independent that it wants to repeatedly reinvent the wheel. Instead of using JNI (the Java Native Interface) to call what are, for all intents and purposes, standard libraries (in our case, OpenLDAP, gssapi, and others) Java brings its own implementations of these, written in Java. Unfortunately, this means that Java libraries are always slower, slow to implement new features and more broken than their native analogs.
2. Writing modern, web-based, Java applications is still dependent on which platform you choose to use: Tomcat, JBoss, WebSphere, Weblogic, Oracle Application Server, and more! All of these might be J2EE platforms but they’ve all their own unique architectures when it comes to security and other features.
3. The Java run-time is huge. In our case (a product I worked on a couple of years ago), no degree of fussing with the Java run-time would get its virtual memory footprint below 200Mb when you added the classes needed web services. The physical memory use was around 50Mb which was a ridiculously large amount of memory for what was essentially a simple management agent.
4. The Java UI classes (AWT, JFC/Swing) are complicated to use and result in applications that are uglier than their native counterparts. Admittedly, it is possible to write Java GUI apps that aren’t terrible (Eclipse, for example) but the fact that it’s so easy to identify Java apps by their contrast with native ones demonstrates the fundamental problem.
5. Java is disliked by Microsoft and Microsoft is disliked by Javans!

This last point is important enough that it warrants further study. Microsoft dislikes Java because it can’t control it. I worked at Microsoft for 11 years (many of them, in the Developer Tools group). Control of APIs and how programmers write software is the single most important asset that Microsoft has. As long as Microsoft owns the hearts (at least, the minds) of the world’s developers it wields massive influence over the software industry.  Microsoft will continue to develop new APIs, tools and goodies for the developer community. Writing web services is ridiculously easy with .NET. Writing forms based application with .NET is equally so. Nothing comes close.

The Java community will generally scoff at .NET and have its own way of doing things. It will take longer to come to market and it will be almost as good. Except, maybe, the UI will look a little off and the Web services implementation won’t completely interoperate with .NET because Microsoft chose to not follow some specification exactly right. For the Java folk, being right is more important than being useful.

So, along comes Miguel de Icaza. If you don’t know Miguel, you should read about him right now. Miguel is a very, very, smart guy. He’s also a fellow Latino — an extra-added bonus. Anyway, Miguel gets the idea to implement .NET on Linux. Since Microsoft made .NET an ECMA standard, they had to document it! Miguel and his team developed a C# compiler and the .NET CLR (Common Language Runtime). They also implemented several of the other Microsoft libraries (including the 1.1 version of the forms library). They did this several years ago and released the Mono project.

The goals of Mono/.NET are similar to those of Java – provide an object-oriented programming system with automatic garbage collection and a set of useful libraries. The advantage of Mono is that it builds on what Microsoft is developing on Windows. You can write your apps for Windows, using Visual Studio for example, and then run them on Linux with Mono (you don’t actually even need to recompile them since .NET compiles source code to intermediate form and it’s the run-time that performs that final native compilation). The Mono run-time is smaller than the Java run-time and since all the necessary HTTP classes are available in the run-time library, it’s easy to implement web-services and web applications without having to bring in Tomcat, JBoss or some other application server. There is a small sample application, xsp, that demonstrates this.

Alas, like Java, Mono, too, fails to deliver the “holy grail”.

Miguel’s company, Ximian, was bought by Novell in 2003. While it’s easy to criticize Novell for not supporting Mono to a greater degree (Miguel has a small team), this is unfair. It is not easy for Novell to “monetize” Mono. The little money it makes off the product it uses to fund Miguel’s team.

Mono works but…for some things better than others. The .NET 2.0 libraries are still not complete. The Winforms libraries are still somewhat fragile. If you don’t have fonts that you can ship with your application it’s difficult to get the same application to look good on both Windows and Linux. Debugging Mono apps is still much, much, more complicated than debugging .NET apps with Visual Studio. A cross-platform debugging solution that allows Visual Studio to perform remote debugging of Mono apps would be killer.

In spite of its limitations, we’ve made great progress with Mono and have been able to port code from Windows to Linux. We’re still strugging with the Mac version and have not had much luck with Mono on UNIX.

Some (well, the Java folk) scoff at Mono. They whine that C# ripped off Java. They say they like Eclipse or IntelliJ better than Visual Studio. They think that supporting .NET is inherently bad because it supports Microsoft. Microsoft loves that kind of talk. Think about it: the pro-Microsoft people write good looking applications, in a very productive manner, that run only on Windows. The anti-Microsoft people write crappy looking applications, in a less productive manner, that run on Linux and, begrudgingly, on Windows (but require installing the JDK and lots of standard-and-OS-independent-but-not-friendly twiddling around). The net result is that users associate Windows with good looking applications and associate portable applications with poor aesthetics and unfriendliness.

Mono is a great way to attract developers to non-Windows systems. Let’s hope that Novell continues to invest (and to increase its investment) in Mono so that it can deliver on its promise.