Historical Backdrop of the War of Who Will Manage Your Code

The idea of managing code to increase a programmer's productivity and the robustness of software products has been around for some time now. It is the level of management that has increased with the CLR and the JVM. Going back to the days when you programmed on a limited budget of memory, you had to be constantly aware of the memory cost of your program, which proved to severely limit a programmer's productivity. A scheme was devised in which a programmer had to worry much less about memory because memory was now “virtual” and a programmer could almost assume that it was in limitless supply. With the CLR and the JVM, the programmer not only worries less about memory (it's no longer necessary to free memory), but the CLR and the JVM have taken over many other functions. Functions such as security, I/O, thread management, type safety, and error handling are now either handled by the environment that is managing your code or greatly assisted by that environment. The problem is that these issues are so broad that much room for interpretation exists on how best to manage code. With the advent of the CLR, managed code can now be essentially split into two camps: the JVM and the CLR. The idea of what technology can best manage your code has become arguably one of the most hotly contested technical issues of the later part of the 20th century, and the battle promises to continue for the foreseeable future.

Since the inception of Java in 1996, many programmers have given up control to reap the benefits of a managed environment. Even Visual Basic has a runtime that manages the code that is run to relieve a programmer from worrying about common tasks. The idea of managed code became so appealing that Microsoft entered the Java market with Visual J++. Microsoft incorporated a JVM as part of the operating system so that the browser could correctly run and display Web pages that had Java scripts embedded in them. This was not enough, however. Managed code still had a stigma surrounding it that it was too slow, the management could be better handled by unmanaged code, debugging was difficult, and so forth. Microsoft successfully “optimized” the JVM and Visual J++ specifically for Windows platforms. The problem was that this was in violation of the license agreement that Microsoft had with Sun Microsystems. After a long legal battle, the courts ruled in January 2001 that Microsoft was to be fined $20 million dollars and restricted from more development on an implementation of Java features after version 1.1.4, on which Visual J++ was based. Although this might seem to be a defeat to Microsoft, in the end, it might be Java's undoing. In July 2001, Microsoft announced that both Windows XP and Internet Explorer 6 would not incorporate any form of a JVM.

The fear in Java camps is that users will not take the extra step to download a JVM, and sites that use Java will need to think of an alternative. Most PC users run a Windows OS. If even a percentage of those Windows users opt out of the JVM option, it could really hurt Java. The battle is just beginning to be fought, and at this point, it's unpredictable how it will turn out. What does this have to do with a JVM and CLR comparison?

This is an important issue. Those at Microsoft and Sun both want your code managed within their framework. For software development to move forward, it needs to be managed. Both the JVM and the CLR seem to be good. It would be hard to pick the CLR over a JVM or vice versa strictly on technical grounds.

In a #1 bestseller by Spencer Johnson, M.D. titled Who Moved My Cheese?, the author allegorically chronicles the experiences of two mice, Sniff and Scurry, and two “little people,” Hem and Haw. The two mice “ignorantly” notice that the cheese is gone and immediately go on to find more cheese. Hem and Haw let their emotions rule their actions, generally feeling depressed and sorry for themselves. Hem and Haw did not start looking for new cheese until it was almost too late. The book teaches many lessons through this analogy, but the one lesson that software developers need to take from this book is to move on when it's necessary. In a way, Microsoft has moved our “cheese.” It's important to understand the new world of managed code, right now represented by the CLR and the JVM, and look for the “cheese” in one of those two worlds. By looking at a comparison of the CLR and the JVM, this Appendix sets out to illustrate many of the common problems solved (in different ways) by each. It also points out how one framework solves a particular problem better than the other.

Comparing many of the features of the CLR with those of a JVM serves as a review of the topics covered throughout this book. By looking at the implementation of a particular feature in the JVM, you can see the CLR in a new light.