Jeff's and Miguel's recent remarks regarding Java performance and .Net portability respectively failed to address the crucial flaw in the Java argument.

I ran starry-eyed into the arms of Java 9 years ago. I build enterprise Java applications in my sad day job. I think I can speak with authority to Java's failings. Both authors of the original documents made claims of 'solution'. I assert that all software exists for the end-user, and a 'solution' that helps the developer, or requires arcane knowledge, solves nothing. Toolkits that allow developers to rapidly create portable code are a necessity to meet business and user needs. But kernels are not simple, and UI is not portable, and the job of the programmer is to make them work for the end-user. Developers must swallow their pride and set aside their ego to make an app that users want.

To the issue of performance, what user knows to switch to a server VM? How many system admins know that tuning the kernel/OS has little affect on the Java VM? I do not relish telling administrators and users that they must set memory and thread parameters in their VM to use an app. Windows 3.0 solved the memory management problem for hundreds of apps, and was in part, responsible for its success. Virtual memory wasn't fixed in Mac OS unit 8.0, but at least the Mac user had an easy means of setting the memory allocation. Tuning the VM's memory and threads is not just an indication of faulty design, it is an impediment to wide adoption. Few users will choose the app that just works with the OS instead of one that requires skilled tinkering to get it right.

Java's portable UI, Swing, is not a solution. Java was quickly adopted by developers, and it is the language of choice for enterprise development. Back in 1995, it was touted as a desktop development solution, it still is in some circles (SUN), but name one desktop app? Limewire is the only app I have ever seen on a normal user's desktop, and that is hardly a killer app. The issue is that the developer is supposed to make an app to satisfy the end-user, and I think the users have rejected Java UI because it is a bad implementation. Does a CHI expert advocate mixing the UI rules? What is the true benefit of an app that can run on any desktop, if the user must constantly pause to consider what he or she must do to make an app do something? Sure a corporation can switch its users from one desktop to another, and the app runs the same, but that is not common. Productivity will still fall because the user is negotiating more rules while working with the computer.

The average user does not switch desktops/OSes. Users do not need an interface that works everywhere. Users need an interface that works with their desktop. Mac users are notorious for this, but Window's user feel the same way too--Java has not succeeded on either desktop. Users want apps the behave like other apps and play well with the desktop. I don't mean look & feel. Java apps that look like an integrated desktop app just delays the user's frustration when their mouse, menu, or keyboard action doesn't work as it does with other apps.

Both Microsoft and Apple had/have very complete native bindings, but even they have failed, in part, because SUN undermines all Java implementations that do not conform to SUN's plans. I have yet to hear SUN speak of gnome-java for creating solutions for it's GNOME-based Java desktop. I'm not criticizing SUN--the Swing interface is perfect for it's native environment, the JavaOS. I'm please with Mono's VM. It seems to behave well with my Linux OS, but I'm certain it will fail if tuning option become a requirement to run an app. As for the GTK# bindings, hurray! My GTK# apps are indistinguishable from my other apps. I don't think about how they were made; they just work.

So to the Mono developers I say, don't stray from your path, because the end-user is at the heart of your solution. To the Java developer, two words. Go native.