Choosing a language for enterprise Windows development isn't as easy as it used to be. C++ has always been the best choice for commercial development, but today's overburdened developers lack the time and patience for C++'s code-compile-debug cycle, made endless by leaks and potholes unwittingly written into the code. Even though Windows C++ programming has gotten easier (what was as unpleasant as a root canal is now a mere poke in the eye), Internet-time scheduling leaves no slack for programmers to fight with their tools.
Note: For more on C#, see the sidebar, "Building the Distributed Enterprise."
TEXTBOX_HEAD: The Bottom Line
Microsoft C# public prebeta
C# simplifies programmers' access to system services while making custom applications less error-prone. C# will eventually be a multiplatform, standards-based alternative to Java, but for the time being it is a smarter, safer C++ for Windows.
- Language specification managed by ECMA
- Access to broad set of object-oriented system services
- Interpreted, runtime compiled/precompiled executables
- Significant performance, overhead penalties compared to compiled C++
- No announced road map for migration beyond Windows
Public beta runs only on Windows 2000
Ship Date No projected commercial availability date
Microsoft Corp., Redmond, Wash.; (800) 426-9400
Compared to C++, Java offers shorter development cycles, safer code, and cross-platform execution. Java is not ideal, being a sharp departure from C++ and generally fitting Windows like a foot in a glove, but Java seems the only smart choice for enterprise projects.
The defection of Windows developers to Java wasn't lost on Microsoft, which hurriedly released a public prebeta of the .Net SDK (software development kit). This 86 MB download is a working preview of what Windows will become, and it includes a compiler for C#, a new programming language pronounced "C sharp."
This Microsoft-devised variant of C++ is relief for beleaguered Windows C++ developers. Unlike C++, and certainly unlike Java, C# provides easy access to native Windows services, including networked objects, UIs, and Internet communication. Like Java, C# greatly enhances stability by preventing common programming errors and automatically managing resources.
Critics warn that C# and .Net are only prebeta, the first tiny step beyond vaporware. Even though it is not cleared for production use, we've been working with C# constantly for almost a month, and the prebeta works so well that some shipping compilers we've used. In fact, the compiler works well enough that developers are already swapping C# code on Usenet and Web forums such as Csharpindex.com (see Resources).
A C# plugin for the Codewright editor is available, and other commercial editor vendors are testing C# support now. One enterprising coder wrote a Web server from scratch in C#, and Microsoft teamed up with Vertigo Software to create a functional .Net e-commerce demo in C# (see Resources).
What's wrong with C++?
Java's creators are critical of C++'s laissez-faire design, which gives C++ developers a free hand, including unregulated access to system resources and the power to reshape the language itself. But the language is as unforgiving as it is powerful. Coding errors can result in resource leaks, invalid or malicious memory access, and other problems that are notoriously difficult to debug.
Java, in the interest of more stable applications, eliminates access to C++ facilities such as manual memory allocation, pointers (direct access to memory) arguments that are passed by reference, and overloaded operators. In return, Java developers gain an easier approach to object definition and usage, automatic memory management, portability across platforms, and a huge library of predefined Java objects.
Java's brilliant design changed enterprise software development. But in doing so it deviated significantly from C++ syntax, slowing Java's adoption by enterprise C++ developers who found some of Java's design choices difficult to swallow.
In contrast, C# is C++ extended with Javalike features, including automatic memory and object lifetime management, interpreted execution, easy access to external objects, and simplified object creation. Useful C++ concepts abandoned by Java, including overloaded operators and reference arguments, are maintained in C#. Pointers, banished from Java as the most dangerous of C++'s features, are not removed from C# but are caged: pointers may be used only in sections of code tagged as unsafe.
|Microsoft built C# to compete with Java, which defines a language-specific framework for enterprise applications. Many of C#'s enterprise strengths come from the language-independent .Net framework|
|Feature||How Java does it||How C# does it||C#'s advantage|
|Automatic management of storage and objects (garbage collection)||Built in to the Java language and the Java Virtual Machine (JVM)||Performed by .Net runtime||Shares storage and objects with all .Net applications regardless of language|
|Object sharing||Local sharing via JavaBeans, remote sharing via Enterprise JavaBeans||Transparently managed by .Net runtime||Can access local and remote objects written in any .Net language|
|Flexible packaging of code||Java classes and packages||.Net assemblies||None|
|Hardware independence||Java bytecode is interpreted by the JVM or compiled en masse at load time||Sections of IL bytecode are compiled just before they are executed||Much faster start-up time, more efficient use of memory|
|Calling functions in native code||Java Native Interface (JNI); native code must be altered||.Net provides access to unmodified .Net COM objects and Windows DLLs||Easy interaction with existing Windows applications, easier phased migration to .Net|
|Object inheritance (adapting objects defined elsewhere)||Built in to Java language||Expressed in C#, implemented in .Net runtime||Can inherit and extend objects defined in any .Net language|
|Enterprise services (messages and transactions)||Requires Java 2 Platform, Enterprise Edition||Built in to Windows 2000||Lower cost, easier application deployment|
Adjusting from C++ to C# is like switching from a stick shift to an automatic transmission. In C++, you must explicitly allocate and free the memory used by objects, whereas C# allocates memory automatically. Memory occupied by C# objects will be freed when an object is no longer in use -- that's garbage collection, a key benefit of Java.
In C++, you must use long lists of included files to gain access to system services, the majority of which are not exposed to your program as objects. In C#, system services are transparently wrapped in C#-compatible objects. In C++, it's difficult to map C++ objects to Windows' COM (Component Object Model), but objects in C# are automatically mapped to the .Net model and can be accessed from any .Net language. .Net objects are expressed using each language's native syntax. The .Net layer makes sure that objects work across languages, so no data conversion or external object mapping is necessary.
The most difficult part of learning C# is training yourself not to pump the clutch and reach for the gearshift. Once you adjust, C# is much easier and safer to drive than C++. Although Java requires that C++ developers learn new ways of doing things, most of the transition from C++ to C# is leaving out the ugly object- and memory-management code written into every C++ application. Allowing the use of pointers and references gives C# developers direct, simple access to facilities outside the .Net framework, including 32-bit Windows DLLs.
We would not attempt to port any Windows C++ application of consequence to Java, but we would convert one, probably in stages, to C#. The resulting application would gain C#'s stability and .Net's cross-language portability. Microsoft seems to have invested considerable care in maintaining easy access to current Windows facilities, even those such as COM that are supplanted by .Net.
Except for modules requiring maximum performance -- that is still C++'s domain -- migrating to C# will be the smartest way to adapt existing C++ applications to .Net. We found that Microsoft's .Net extensions to Visual C++ make integration with C# code quite easy.
Let's move on
C# is so much like C++ that it provokes little excitement by itself. C# exists because Microsoft needed a Javalike language for .Net, but Java itself was out of the question.
Some of us are C++ developers and thus appreciate that C# keeps most of the quirky, powerful C++ features we like. Regardless of Microsoft's motives, we appreciate that C# flew straight into the hands of the ECMA. ECMA manages the language, so we will see non-Microsoft C# tools and compilers as well as contributions to the language from other learned sources.
Third parties creating C# tools won't have to license the language from Microsoft, so the cost of tools should remain low. In contrast, Sun withdrew Java from the standards track, so only Sun can forward the evolution of Java.
C++ will also remain the Windows performance champ, being the only Microsoft language that can compile directly to native code instead of IL.
Sweetening the deal, still more languages are on the way. Third parties have already signed up to do COBOL and Eiffel compilers for .Net; your .Net developers can code in the languages they know best and like most. That means less ramp-up time, lower training costs, cleaner code, and happy, productive developers.
A substantial part of this vision is already in place. Our efforts to break cross-language object access failed utterly, even in the prebeta. Now it's up to Microsoft to create an IDE (integrated development environment) that brings multilanguage project teams together. That's Visual Studio .Net, and that, as they say, is another story.
The first task for C# is to give C++ developers access to the .Net framework. That is no small thing, because .Net is destined to be the heart of Windows enterprise applications. At the recent Professional Developers Conference (PDC) in Orlando, Fla., where .Net made its debut, Microsoft made it clear that .Net is not only hardware-independent but also highly portable across OSs.
Microsoft is wisely keeping mum about .Net migration plans; getting .Net running on Windows is understandably its top priority. But we'd lay odds that .Net will soon roost in Solaris or Linux. Once .Net extends its reach beyond Windows, C# will become a true Java competitor. Until then, C# is a well-hewn successor to C++ for enterprise Windows applications. That's not a bad start.
Learn more about this topic
- For JavaWorld's other product reviews, see our Product Review section of the Topical Index
- Microsoft and Vertigo Software .Net e-commerce demon in C#
- C# Web forum on Csharpindex.com