• Shawn Bayern, the JSTL reference-implementation lead, is the author of the pending JSP Standard Tag Library and co-author of Web Development with Java Server Pages. He will carry the torch for Java.
• Tom Cabanski, president of Objective Advantage, Inc, will carry the torch for Microsoft. He is the author of the pending text, .NET Security.
  Bruce Tate, president of J2Life, LLC, and author of Bitter Java, will moderate the debate. The opening arguments are below. The first rebuttals will be posted in two weeks.

Microsoft .NET will beat Java

Microsoft .NET will beat Java in the marketplace. When I started the research for this debate I thought I would have no problem proving my point. All I had to do was explain how Microsoft .NET was going to blow past Java on the strength of its technology, the power of Microsoft's marketing machine and Windows' leading position in the desktop and server OS markets. The truth is more complex. Unlike in past battles, Microsoft .NET faces a very effective competitor that is rapidly becoming entrenched in both business and academia. To make matters worse, Microsoft's dominant position on the desktop appears far less valuable than it has in the past because desktop growth has slowed. In addition, the rapidly growing wireless device market, where Microsoft has had little success, looks like it will be dominated by embedded Java. When you add in well-publicized security holes and the distraction of antitrust you have to start to wonder.

Microsoft's market leading position is the core issue

Even so, Microsoft .NET will beat Java in the marketplace. As young as .NET is, it is already technologically up to the challenge. Over the year or two it will just get better. Visual Studio .NET is better than the best Java IDEs on the market. Meanwhile, Microsoft's leading position in the industry coupled with its talent for marketing platforms to both developers and decision makers guarantees that .NET will gradually gain momentum. The only question that remains is whether or not .NET will remain tied to the Windows platform and whether it can succeed if it does.

Although the two platforms evolved in different ways, they ended up with a very similar set of features. Some folks in the Java community will argue that this is because .NET is nothing more that a Java rip-off. In truth, .NET resembles the Java platform because it solves the same problems. The biggest difference is how the two platforms position their virtual machine (VM). Sun's literature says that Java's VM was designed to allow any Java program to be run on any platform with a compliant VM. On the other hand, Microsoft emphasizes that their virtual machine, called the Common Language Runtime (CLR), was designed to allow code written in any language to run under .NET, which is primarily associated with Windows. This difference reflects both the respective marketing position of the companies involved and the lineage of the platforms.

Microsoft supports multiple languages

Microsoft supports multiple languages in .NET because their installed base of developers uses Visual Basic, C++, and, to a lesser extent, Java. As a side effect, they were able to allow support for just about any language including popular legacy languages like COBOL and FORTRAN. Projects using one language can exist in the same solution as projects written in another. Provided you stick to CLR-compliant types, classes written in one language can even call classes written in another. There are compromises, especially in legacy languages like COBOL that support non-ANSI (and non CLR-compliant) numeric types, but it sure is impressive. Multiple language support will pay tremendous dividends because it shortens the .NET learning curve. After all, programmers will not have to learn another language to move to .NET. They can also port logic from their old code directly to .NET.

Java supports multiple platforms

The cross-platform comparison is more confusing. Sun emphasized cross-platform capabilities from the beginning because they saw "write once, run anywhere" as a way to wipe away Microsoft's dominance in the computer industry by replacing Windows with a broader platform. The whole idea of the network as the computer revolved to a certain extent around Java. As Oracle's Larry Ellison discovered, that strategy is still a bit flawed. However, the fact that Java runs on just about every computing platform in existence makes it a lot easier to choose. Sun licenses Java to anybody that is willing to develop a pure Java implementation for their platform. As a result, Java really is everywhere. It's on Windows, Mac and every flavor of UNIX you can find. It is available on mainframe and minicomputer operating systems like MVS and MPE/iX. It's starting to show up in phones, PDAs and even in appliances.

Microsoft multiplatform support will happen too

The .NET architecture is also inherently capable of delivering "write once, run anywhere", but Microsoft has failed to exploit this so far. They have only delivered .NET for the desktop, server and mobile versions of Windows. Although they seem happy enough to mention efforts to bring .NET to other operating systems, like the Mono .NET project for Linux, they certainly have not emphasized or blessed them in any way. Microsoft has yet to find a partner interested in bringing .NET to their operating system. As baffling as this all appears, it makes sense from Microsoft's point of view because they still earn most of their revenue from sales of operating systems. Score one for Java here but just keep in mind that there is nothing technical standing in the way of bringing the CLR to lots of platforms. I think Microsoft will wake up to this before too long.

Java's emphasis on platform neutrality gives it an advantage in the embedded software arena too. Right now it is being rapidly adopted for use in cell-phones, pagers, PDAs, set-top boxes and home appliances. Microsoft, on the other hand, has not had as much success with Windows CE, their embedded operating system. However, each version of Windows CE has been better than the last and momentum is building. .NET is already available for Windows CE. As many have discovered, Microsoft is very good at displacing the apparent advantage of a first mover.

Microsoft .NET and Java are mostly equal

Java and .NET are mostly equal in other technical areas: Both support true OO languages with single-inheritance and garbage collection; Both ship with large libraries of objects that cover UI, file IO, security, web access, collecting objects and other useful standard functions; Both support remoting; Both support transactional components; Both support database access through technologies designed to allow database portability; Both support creating sophisticated web applications; Both support code security; and they have many more things in common.

There are, of course, subtle but real differences in implementation that we could argue about for hours on end. Other differences are more significant. For example, the J2EE standard allows Java to work with a variety of third-party application servers to provide transaction, connection pooling and message queuing capabilities; but Microsoft .NET currently supports only the transactional and message queuing capabilities built into Windows. .NET includes a couple of unique performance-enhancing features like a library for direct access to Microsoft SQL Server and a very nifty facility for caching dynamic pages in memory to improve performance. Java currently includes some object-relational mapping features that .NET will not have until some time in the future. The bottom line is that neither platform is technically superior. They both get the job done.

Microsoft has a strong IDE

Microsoft's IDE, Visual Studio.NET (VS.NET), is as good as or better than any Java IDE on the market. In general, it does what you expect and then goes at least one step further. One of my favorite features is the way it checks syntax and highlights errors as you type. The error description shows up when you place the mouse cursor over the highlighted syntax.

Most importantly, it includes built-in support for discovering and reading the definition of web services based on the Internet-standard SOAP and UDDI protocols. This makes it easy to build applications that consume web services. Even the debugger is somewhat incredible in that it can step seamlessly from local code, to remote code and even into stored procedures provided you are using Microsoft SQL Server.

Cost neutralizes some advantages

When you look at the big picture it is clear that .NET will win this battle. It has most of the same technical capabilities as Java. It is not as cross-platform yet, but the cross-platform argument will be addressed by third-party and open source efforts in the near future. Once of Java's biggest technical advantages, its support for a large number of powerful application servers, is mitigated by high cost. This is especially true when you consider that most of the features they provide are built right into Windows. The VS.NET IDE lowers the bar for developers by providing plenty of features to make developing systems easier.

Ultimately, Microsoft marketing muscle will decide

Finally, don't underestimate the power of the Windows franchise and Microsoft's marketing ability. Microsoft knows how to reach out to developers and decision makers. They do it better than anybody else. Many more companies will choose .NET because of Microsoft than will choose Java because it is not from Microsoft. The evil empire argument just won't apply.

Tom Cabanski is president and co-founder of Objective Advantage, Inc. He is the author of the pending text, .NET Security.

Rebuttal

Java will beat Microsoft .NET

Newcomers to Java and .NET might be struck by how similar the two competing platforms are. This is no accident: Microsoft and the Java community are engaged in an arms race. Neither platform can take a good idea very far without the other side's noticing.

Therefore, while many comparisons of Java and .NET focus on the goals and capabilities of the two platforms, that approach seems pointless. The two competing technologies can pretty much do the same things, and they share the same goal: to attract as many developers as possible. Indeed, their differences are mostly stylistic and aesthetic. However, as someone who researches and develops technologies for a living, I've come to a clear decision: Java suits me, and most people I encounter, better than .NET. In this short article, I'll explain some of the reasons why.

Wait! What is .NET?

If you're a Java developer -- and perhaps even if you work with Windows -- you might not yet know what .NET is. In fact, Microsoft uses the term ".NET" to describe two completely different things. First, .NET is a framework for web services, or XML-accessible components. However, web services are actually one thing Microsoft doesn't have a monopoly on. They represent a simple, platform-independent concept that can be realized just as easily with Java as with .NET. The topic is therefore not a useful way to distinguish the two platforms, and I won't discuss it much in this article.

Instead, we'll focus on the other meaning of ".NET", which centers on Microsoft's Common Language Runtime (CLR). This is a new framework for developing and executing software, and it represents .NET's technical core. This is the half of .NET that we can sink our teeth into and compare to Java.

1. C# versus Java

We'll begin the comparison by looking at C#, the CLR's core language. Although .NET allows developers to use multiple languages -- as we'll discuss later -- C# in many ways represents .NET's design center. Broadly, C# is a successor to C++, and it actually borrows many good ideas from Java.

However, in the words of James Gosling, Java's founder, it also adds a number of features that are "outright stupid."

For example, one of the things that motivated me to begin to use Java, many years ago, was strict error checking, known as exception handling. In fact, this issue became so important to me that I consider poor exception handling a show-stopper for a programming language.

Java's exception handling has the same goal as professional accountants: it makes sure no item is forgotten or swept under the rug. The exception handling in C#, however, is closer in spirit to the accounting practices of Enron: in C#, a programmer can simply ignore exceptions if it suits his immediate purposes. More technically, a C# method that throws an exception doesn't have to -- and, in fact, can't -- declare formally that it throws it. The end result is that it's much harder to answer the simple question, "Does your program work?" If I don't even know what errors an API I use might encounter, how can I reasonably be expected to account for them? Java's exception handling does allow sloppiness in the wrong hands, but overall, it helps ensure that potential errors are handled properly.

As an example of another major problem, the fact that C# lets you use C-style pointers is disastrous. C# lets you write error-prone code, with the potential to wreak havoc with your program's address space, as long as you mark the code as "unsafe." This is reminiscent of a sign I recently saw at a restaurant in the Chicago airport: "By law, we are required to post that we have failed a health inspection within the last two months." (Guess whether I ate there or not.) The fact that a library might contain "unsafe" code should be enough reason to avoid using it in the first place.

In fairness, C# does add a number of useful syntactic features beyond what Java provides. You can write code to loop over data a little more easily in C# than in Java. C# makes it easy to set up JavaBean-style properties, and its 'switch' statement works better than C's and Java's. But these features are insubstantial; they represent minor syntactic conveniences rather than major, revolutionary changes. The significant differences between Java and C# all point in one direction: C# facilitates the poor programming practices that Java's design intentionally avoids.

2. Multiple languages

Microsoft presents .NET as a platform that supports interoperability and portability. In practical terms, the true cross-platform portability of .NET -- that is, the chance that you'll ever run any C# code on your OpenBSD laptop -- is somewhat negligible. But .NET does support multiple general-purpose programming languages, and this raises an interesting question: Is it important to let languages interact at the API level in order to meet the needs of diverse programmers?

Ultimately, I think the answer is "no" and that this ability of .NET is illusory. The computing industry isn't currently limited by the failure of languages like COBOL, Perl, and Eiffel to interact programmatically. Most languages can already read the same files as one another, write to the same databases, and interact with the same users. .NET doesn't magically transport legacy applications to the modern world. Instead, it simply allows new extensions to be added to languages like COBOL so that they finally work satisfactorily on Windows. The end result is a series of languages that can all do the same thing, in slightly different words and with slightly different organizational concepts.

Java takes a different approach. Instead of promoting a collection of overlapping, general-purpose languages, the Java platform seems to be moving decisively in favor of focused, task-specific languages. Programmers recognized long ago that some tasks deserve special languages of their own. For instance, we access databases with the Structured Query Language (SQL); we manipulate XML documents using XSL Transformations (XSLT) and the XML Path Language (XPath); we solve quick systems-related issues using shell scripts. This spirit manifests itself in upcoming Java standards like the JSP Standard Tag Library (JSTL), which provides essentially a new, high-level language for web development. The force is seen also in the next revision of JSP, which will likely include a typeless language for referring to objects stored in memory.

Thus, with the Java platform, programmers can choose a language with as much structure and type safety as they want. Instead of being presented with general languages that overlap or whose designs contradict one another, they can choose from an array of focused languages designed, from the ground up, with them in mind. For instance, HTML designers who know some JavaScript can pick JSTL and a typeless expression language; advanced developers, by contrast, can work on application frameworks using servlets and the full power of Java.

The languages currently available to the .NET developer suggest no such forethought. Instead of providing true flexibility and ordered division of labor, they merely provide alternative syntaxes for the same basic tasks. For those of you who invest your money in the stock market, the difference is a little bit like having to pick from among a dozen similar mid-cap stock funds (on the .NET side) versus an array of choices with meaningfully different risks and rewards (with Java).

Finally, Java and the languages it supports can run everywhere. .NET is still, for all practical purposes, stuck with Windows.

3. Community support

The Java community has a major advantage: it's a community. Java isn't developed by a single organization; it's a growing architecture supported by most of the industry.

If you're skeptical of the open software "community", keep in mind that the Java Community Process (JCP) isn't some self-important collection of unkempt undergraduates and geeks trying to overthrow corporate America. In fact, the JCP is driven by professional collaboration among major firms like Sun, Oracle, IBM, HP, Macromedia, BEA, and Compaq. This situation -- and, I freely admit, the infusion of ideas from unkempt undergraduates and lifelong geeks! -- promotes interoperability and good design.

Is community-driven support slow or inefficient? Experience suggests that it isn't; so far, Java has been able to adapt quickly to the changing marketplace. For instance, Java developers can often download "early-access" releases of new technologies. (One good example of this is the new "Web Services Pack" from Sun, which makes it easy to develop web services with Java.) Packages like this both facilitate quick adoption of new standards and promote community feedback.

Summary

.NET represents a number of new ideas, and it borrows some good existing ideas from Java. However, it's crippled by technical missteps and a design centered on a single operating system.

Since it lacks a clear technical advantage, the only way for .NET to rise to primacy is for Microsoft's sheer marketing force to propel it there. This might be possible, but in this age of increasingly savvy developers, I wouldn't bet on it.

Shawn Bayern is the JSTL reference-implementation lead, is the author of the pending JSP Standard Tag Library and co-author of Web Development with Java Server Pages.

Rebuttal