University of Waterloo Faculty of Mathematics

A Comparison of Java to C# and Microsoft.NET

Copyright December 2001 by Graydon Armstrong

Table of Contents
Executive Summary Introduction Analysis Language Java C# APIs Java .NET Documentation Java C# and .NET Other Considerations Java C# and .NET Porting Issues Conclusions Recommendations References 3 4 4 4 5 5 7 7 7 9 9 10 10 11 12 13 14 15 16

Graydon Armstrong

A Comparison of Java to C# and Microsoft.NET

Executive Summary
This report examines and compares Sun Microsystems Java programming language and associated APIs with Microsofts C# programming language and .NET APIs. The basis of evaluation is a combination of factors, primarily including power, flexibility and ease of use. Cost is not an issue, as all three packages are available freely. This report concludes that Java is preferable to C# and .NET, due mainly to a poor design of the .NET APIs and Microsofts relative lack of compatibility with other software. The report recommends considering scaling back .NET development to a core set of features, until it is determined whether .NET really catches on in industry.

Graydon Armstrong

A Comparison of Java to C# and Microsoft.NET

Introduction
Microsoft in late 2000 made available a public beta release of their latest development initiative. The .NET framework combines a new language, C#, with a set of APIs and a virtual machine; on the surface it sounds very much like Java.

Sun Microsystems Java platform, which debuted in 1995, has become quite popular in industry due to its type-safe object-oriented design, portability, flexibility and simplicity.

This report compares the Java platform to the C# language and .NET APIs, and also discusses issues encountered porting code from Java to C#.

Analysis
Comparative analysis of the two platforms is based primarily on criteria of power, flexibility and ease of development. Cost is not an issue at this time, but Microsoft may charge for .NET tools in the future.

Language
A strong programming language can be the foundation of a strong development platform. A clean, logical design balancing power and simplicity is of great importance. Developers may abandon a crippled language lacking in power, and may become frustrated with a language that is unnecessarily complex.

Graydon Armstrong

A Comparison of Java to C# and Microsoft.NET

Java
Sun Microsystems Java language made its debut in 1995 when it was evolved and renamed from Oak. The language itself is similar to C++, but for simplicity, does not contain features such as pointers, structs, enums, operator overloading, multiple inheritance or templates. C++ developers may bemoan such omissions, but there is elegance in this simplicity; code for a Java solution is generally relatively clean, if somewhat less efficient.

C#
Microsoft released the first public beta of their new C# language and .NET framework in late 2000. Although very similar to and clearly designed to compete with Java, C# supports many of the features of C++ that were dropped from Java and adds new ones as well. The result is a very powerful language, but one which is also quite complex (possibly excessively so); C# has almost 20 more keywords than Java. Many of these keywords are used to mask simple functionality. For example, the foreach keyword masks what is really a for loop using an enumeration. While the keyword is convenient, such functionality probably does not belong in the language specification.

Other features introduced in the C# language are very welcome. Indexers allow access to elements of a collection in a style similar to array access, by specifying the index in square brackets. This results in cleaner and more readable code, and is employed with particular frequency by the collections and data access frameworks. Properties in C# have advantages and disadvantages. They take the place of Javas getter and setter methods, allowing a property value to be stored or retrieved as if it were just a variable. In many cases, this functionality would be used to check data validity before 5 Graydon Armstrong A Comparison of Java to C# and Microsoft.NET

storing the value or to perform simple processing on the value. However, since the act of accessing a property is really a method call, and the property body code is a regular method, it is entirely possible to encounter the disturbing situation in which an exception is thrown during access of what appears in code to be a regular variable. This is unsafe operation, the danger of which is only exacerbated by C#s lack of checked exceptions.

C# does not support checked exceptions; methods are not required to declare exceptions they throw. This was a very dangerous design decision. When calling a method in C#, it is impossible to tell whether an exception can be thrown, except by referring to the API documentation, which may or may not be correct or current. In most production systems, it is not desirable to have an exception propagate down the stack to a level where it may crash the program. Therefore, in order to ensure stability, developers may be forced to put bits of code within try blocks and catching any exception. This is not good programming form; catches should be specific. Also, this ends up cluttering the code. Apparently this design decision was made because Microsoft felt the trivial try and catch blocks that often appear in Java were clutter. Also, to propagate an exception down the stack in Java, each method along the way must declare the exception to be thrown. These are valid concerns, but the stability issues are much more severe.

In summary, C# is a powerful language, but like much of the rest of .NET, some aspects could have been better thought-out.

Graydon Armstrong

A Comparison of Java to C# and Microsoft.NET

APIs
APIs are libraries of classes implementing core functionality and concepts required by applications. The API design can make or break an otherwise good language.

Java
The core Java APIs are very well designed in most cases; they are a product of years of evolution. Of particular strength is the Java collections framework, a well-thought-out group of collection interfaces and a variety of implementations of sets, lists, and maps.

The core Java APIs will grow significantly in size with the upcoming release of Merlin (Java 1.4). Support will be added for, among other things, logging and non-blocking IO. The future of the Java APIs looks bright.

.NET
The design of the .NET API used by C# is, in short, unjustifiably poor. The developers at Microsoft had a clean start, a chance to do everything right, and they fumbled the opportunity badly; a few poor (and quite illogical) design decisions seriously cripple what would otherwise be a reasonably good set of APIs.

Of particular disgust are the poor implementations (or lack thereof) of the Equals and ToString methods. Although the problem is widespread throughout the .NET APIs (suggesting it was a definite design decision), nowhere is the problem more apparent than in the collections framework.

Graydon Armstrong

A Comparison of Java to C# and Microsoft.NET

Microsoft decided that the Equals method should check for referential equality, not equivalency of content. Thus, any program wishing to check, for example, if two collections contain all the same elements, must write their own comparator method. The issue becomes even more complex if collections are nested. This was a ridiculous design decision on Microsofts part; for the few occasions when a program does need to check referential equality, there is the equality operator.

Less severe but a definite annoyance nonetheless is the ToString method, the default operation of which is to return the type name of the object. In normal operation, most programs will not have cause to call ToString on a collection. However, displaying a text representation of a collection can be invaluable during the development process, in particular while debugging. Considering the uselessness of the default functionality, and the trivial amount of code required to override it to provide a useful function, one can only label this as another poor design decision by Microsoft.

Finally, the APIs are not wonderfully organized, although this is more of a style issue than a real problem. There are hundreds of enums, classes, delegates and such that should have been written as nested classes because of their applicability only in the context of the would-be outer class. Instead, they clutter the main namespaces. Worse, many of these classes seem to be crying out for templates; in many cases the only difference in functionality to the superclass is the return or parameter type of some methods. If Microsoft considers extending classes in such a way to be an acceptable practice, then C# should have included support for templates.

Overall, the .NET API leaves so much, yet so little to be desired. Fixing but a few small but glaring problems would have resulted in a good API, but apparently this was not to

Graydon Armstrong

A Comparison of Java to C# and Microsoft.NET

be. Unfortunately, it is likely too late to remedy these problems, as doing so at this point would break countless pieces of software already developed for .NET.

Documentation
Documentation is a key resource in development on any platform. Java defined a standard format for code documentation and provided tools to compile it to HTML. C# provides similar functionality. Good documentation can be a significant factor in encouraging adoption of a technology.

Java
The Javadoc documentation system, while not technically part of Java, certainly deserves mention. It is not unreasonable to suggest that Javadoc has been one of the main factors driving widespread adoption of the Java platform. By defining a standard format for documenting code and providing the Javadoc compiler, Sun has made it easy to produce excellent HTML documentation of APIs. This facilitates and thereby encourages third-party development. Likewise, in-house productivity is improved by virtue of having available quick reference for libraries used by the code under development.

C# and .NET
C# appears to have a documentation standard, similar to Javadoc, but based on XML. Ironically, at the time of writing, meta-documentation for C# is difficult-to-impossible to find; a search of the MSDN Library turns up no documentation about the documentation format. The only suggestion that such a format exists comes from the auto-format and auto-complete features in Microsoft Visual Studio; when a developer begins a comment in an appropriate context, Visual Studio sets it up with XML tags in what one can only Graydon Armstrong 9 A Comparison of Java to C# and Microsoft.NET

presume is the C# documentation format. The documentation can be compiled into XML with a command-line tool, but no apparent tool is yet provided to transform the XML to a readable HTML format. One can hope that when such a tool is eventually provided, that the generated HTML will be of a simple format similar to Javadoc, and not like the .NET API documentation in the MSDN Library, which is heavyweight and unnecessarily convoluted.

Graydon Armstrong

10

A Comparison of Java to C# and Microsoft.NET

Other Considerations
Quality is not the only factor in a comparison between two technologies such as Java and .NET. Issues such as costs and levels of industry adoption must also be addressed.

Java
Java already has a large developer and user base. It is very platform independent; the Java virtual machine has been ported to literally scores of operating environments, including Windows, Linux, Solaris, BSD, MacOS and virtually every flavour of Unix, not to mention high-end server platforms such as IBM OS/390 mainframes and handheld devices such as the Palm platform. Chances are, if someone runs it, it runs Java.

Java development tools are also prolific. A variety of compilers are available, many for free, as are profilers, debuggers, testing APIs, and other tools.

Java is open-source, subject to licensing terms. Source code for the APIs is included in the Java Development Kit. It is certainly beneficial to developers to be able to see API source code, as it promotes greater understanding of what is occurring behind the scenes, and in some cases allows optimization for these processes. Additionally, if an API feature is not adequately documented, a developer can peek at the source to determine what the feature does and how it works.

C# and .NET
.NET is a relative newcomer to the marketplace, and as such, one cannot yet expect it to have the wide platform support enjoyed by Java. Microsoft has so far only released the 11 Graydon Armstrong A Comparison of Java to C# and Microsoft.NET

.NET framework for their Windows platform, although a port to FreeBSD is apparently in the works. This may be simply a token port to allow .NET to claim cross-platform compatibility; the .NET APIs appear to be quite Microsoft-centric; documentation of some classes suggests their functions are clearly only applicable to a Windows machine, and the data access classes are designed to use Microsoft SQL Server. Microsoft seems intent on locking consumers into their technology in this way, and this is a dangerous trap. On the plus side, though, it is reasonable to expect Microsoft software to work efficiently together.

Currently, .NET development tools such as the C# compiler are available for free download from Microsoft. This may change with the final release of .NET, however, and should be considered in a decision to develop for .NET.

The .NET API is closed-source, although a subset of the framework has been approved as an ECMA standard and so a reference implementation of this subset may be provided.

Graydon Armstrong

12

A Comparison of Java to C# and Microsoft.NET

Porting Issues
Because both Java and C# have their roots in C++, all but minor aspects of the grammar are identical. Many of the .NET classes are isomorphs of their Java counterparts. As such, it is a fairly trivial task in many cases to port Java code to C#.

In general, there are no major language issues that arise during porting. C# uses a namespace block and using statements instead of Javas package declaration and import statements; this is trivial to convert. A C# type declaration is in the C++ style, with the class name followed by a colon and a comma-delimited list of the type it extends and/or the interfaces it implements (as opposed to Javas extends and implements keywords). In C#, the superclass is accessed with the base keyword (super in Java), and its constructor is called in the C++ style.

A final language issue that often escapes preliminary detection is C#s virtual and override methods. In Java, methods are virtual by default; subclasses may override their implementations to provide isomorphism. In C#, this is not the case. Methods must be explicitly declared virtual if they are to be able to be overridden. The overriding method must also declare with the override keyword that it overrides a method. This issue can frequently cause runtime problems, which become apparent when normally-overridden methods such as Equals seem to be misbehaving; really, the default implementation (referential equality check) is being used.

Often, the only difference between the names of Java methods and their .NET counterparts is the capitalization. The .NET naming standard is for all namespaces, types, methods, properties, fields and constants to be named using the InitialCaps (e.g. ArrayList, CompareTo) style. The initialCaps (e.g. startIndex, myString) style is used for 13 Graydon Armstrong A Comparison of Java to C# and Microsoft.NET

local variables only. Note that in an executable class in C#, the main method is called Main.

A full discussion of porting issues is beyond the scope of this report, but they may be rendered irrelevant anyway if Microsoft releases the JUMP to .NET (Java User Migration Path to .NET) tool it announced long ago. The tool would automate the conversion of Java code to C#. In the meantime, there exists Visual J#, which allows coding for .NET to be done in the Java language. Since the main issue in porting is in dealing with the API differences, though, there is no reason not to port it all the way to C#.

Conclusions
Java is a much simpler language than C#, yet it lacks little of the power of C#. Its APIs are much better designed than the .NET APIs, and Java already has a large developer and user base. Considering that .NET had a fresh start, unconstrained by requirements of backward compatibility, its offering could have been much better.

Java will likely remain a powerful force in the industry for years to come. It remains to be seen whether .NET will be a real contender; if it is, it will likely be in no small part due to Microsofts marketing clout and their lock-in strategy.

Graydon Armstrong

14

A Comparison of Java to C# and Microsoft.NET

Recommendations
Ideally, development in only Java would be sufficient. The .NET API is poorly designed, and it remains to be seen whether it will be truly accepted by the industry. However, customer requirements may demand support for .NET. Currently, the task of porting Java code to C# is awkward, but viable. However, as the code increases in complexity, difficulties in porting may increase in number and severity.

The recommended course of action is to focus primarily on development for Java. Porting to C# should be done only in cases where the work required to port is trivial or where key functionality is implemented by the code in question. Clients should be encouraged to use Java solutions wherever possible.

This issue may need to be reopened at a later date. If porting becomes a significant time sink without much payoff, it may be worthwhile to abandon .NET. Conversely, if the API is improved or gains wide acceptance in industry, it may make sense to provide full support for .NET. Either course of action can be undertaken with minimal costs. Abandoning a minimal set of ported code is not a big deal, and neither is adding functionality to that code.

It may not seem wise to wait sitting on the fence about this issue, since time is of great importance in software development. However, the proposed solution allows for quick development around a minimal existing ported code base should the need arise while at the same time insulating the company from danger should the .NET initiative be a flop.

Graydon Armstrong

15

A Comparison of Java to C# and Microsoft.NET

References
Java 2 Platform Standard Edition v1.3.1 API Specification http://java.sun.com/j2se/1.3/docs/api/

Java 2 Platform Enterprise Edition v1.3 API Specification http://java.sun.com/j2ee/sdk_1.3/techdocs/api/

The Java Language Specification (Second Edition) http://java.sun.com/docs/books/jls/second_edition/html/

C# From A Java Developers Perspective http://www.25hoursaday.com/CsharpVsJava.html

.NET Framework Class Library http://msdn.microsoft.com/library/en-us/cpref/html/cpref_start.asp

C# Language Specification http://msdn.microsoft.com/library/en-us/csspec/html/CSharpSpecStart.asp

Java Resources Overview http://www.geocities.com/marcoschmidt.geo/java.html

Graydon Armstrong

16

A Comparison of Java to C# and Microsoft.NET