Currently a factor which is affecting .NET's popularity in particular is the runtime deployment problem. If the user only had to install it once (the fantasy) the problem would be limited, but the reality has been that .NET has been constantly updated and if you distribute a .NET program the great majority of your users will have to install the runtime either because they do not have it all or because they have an older version. The .NET runtime weighs in over 20 MB with many dialogs. It takes over an hour for a programmer or power user to download and install the runtime (translation for ordinary users: all afternoon). This is huge barrier because it means that for even the simplest program the user must spend all afternoon installing the runtime--something that they do not understand the purpose of anyway. The user is going to think, "Why am I doing this?"

The other big problem with the .NET runtime can be ascertained by the use of the word "download" in the above paragraph. Unlike Java the 22 MB of physical files of the .NET runtime cannot be moved physically to the client. The user must explicitly download. Microsoft provides an executable called dotnetfx.exe (fix?) which .NET developers can provide their customers to moderate this download, but this does not solve the essential problem that the user must download the runtime. That means if they lack a high-speed internet connection they are not a customer which means you can pretty much forget retail sales. Another penalty for the dotnetfx handoff is that the installation process leaves the control of the developer. Your program basically says to the potential user, "Here, install this gargantuan, system-altering program on your computer and when you are done we can continue." If anything goes wrong the developer is out of the loop. My experience with handoffs like this is that in most cases the handoff will not complete for one reason or another (doesn't work, user loses patience, user screws up, etc). Starting to understand why there are no .NET programs out there?

This whole experience differs vastly from the old VB runtime installation. In the old days the VB support would be more or less embedded in your installation program so (1) it was invisible to the user, (2) it installed in a context you could control and (3) you could distribute the files on media like a CD--no need for a network connection. The main threat to the VB runtime installation was DLL hell but since the developer controlled the install there was the opportunity (with enough programming) to mitigate or prevent most problems. Microsoft's new policy of leaving the developer out of the loop and just trusting dotnetfx.exe to operate perfectly for all systems is highly questionable.

Java is similar to the old-style VB, Sun allows you to distribute the runtime files so you can put everything on a CD. The user never knows they are using Java, which is what you want. The runtime should just work and be invisible to the user. Since the Java runtime requires no registry settings it is much easier to install than the old VB runtime. You just copy the files to disk and you are done. My main gripe is that while the Windows runtime is reasonable in size, the Linux Java runtime is hefty, about 19 M, nearly as much as .NET. For a CD distribution this does not matter, but for an internet download it means our program weighs in around 25M which can take over 10 minutes for a garden variety work connection. My feeling is that any install which takes over 10 minutes is pushing it.

If you have a simple program often you can sidestep the whole runtime problem with Java because nearly all users have a Java runtime installed as part of their browser setup. As long as your program only uses the AWT you can bet it will run on pretty much any machine made after 2000. Even if your program uses Swing you have a 50-50 shot of running with no runtime installation.

In my earlier article I focused on the functionality-related issues between .NET and Java but in the real world it is often the practical considerations like runtime deployment that end up dominating usability.