Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

C#: A language alternative or just J--?, Part 2

The semantic differences and design choices between C# and Java

By Mark Johnson, JavaWorld.com, 12/21/00

  • Print
  • Feedback
.

Page 5 of 5

Operator overloading

Operator overloading lets you define how operators can be used with their classes. Operations on instances of those classes can then be expressed in expression notation using the operators, rather than as explicit method calls. Operators used in expressions map directly to the class's operator overloading definitions, subject to the language's rules for operator precedence and associativity. Mathematics packages often use operator overloading to provide a more intuitive programming model for their objects. For example, instead of matrixA.matMul(matrixB), the operator called operator* can be overloaded to handle matrix multiply,

yielding matrixA = matrixA * matrixB;.

Unlike Java, C# permits operator overloading, using a syntax almost identical to that of C++. Some operators that can be overloaded in C++, such as operator=, cannot be overloaded in C#. Experienced C++ programmers will have to learn and remember the differing rules for C# operator overloading, despite the almost identical syntax.

In light of their experience with C++, Java's designers decided deliberately to leave operator overloading out of Java. The question of operator overloading in Java is an ongoing debate. Fans of operator overloading claim that leaving it out of the language makes some code unreadable, if not virtually unwritable. Many in the numerics community would like to see operator overloading added to Java. Overloading detractors say that operator overloading is widely abused and that it all too often makes code unmaintainable. For the time being, the free program JFront (whose name is a pun on CFront) provides a preprocessor that implements operator overloading for Java (see Resources).

Methods

C# methods have some features that Java does not. In particular, C# provides several modifiers on method parameters and has keywords for virtual methods and method overriding.

As in C, C# method parameters are value parameters. The ref modifier on a method parameter makes that parameter a reference, so any change to its values is reflected in the caller's variable. The out modifier indicates that the parameter is an output parameter, which is identical to a reference parameter, except that the parameter must be assigned definitely before the method returns. The params keyword allows variable-length argument lists. For example, a method to print an arbitrary number of items might look like this: 

#import main
void PrintItems(params object[] values) {
   foreach (object value in values) {
      Console.WriteLine(value);
   }
}


C# methods are, by default, nonvirtual but can be made virtual by explicit use of the keyword virtual. The C# virtual keyword in a base class defines a method as virtual. Subclasses must use the override modifier to override inherited virtual methods. Without the override modifier, a method in a subclass with the same signature as an inherited virtual method simply hides the superclass implementation, although the compiler produces a warning in this case. The keyword new, used as a method modifier, hides the superclass implementation of an inherited virtual method and turns off the error message.

C#'s designers went to a great deal of trouble to create fine-grained control over method overriding and hiding, which interacts in various subtle ways with accessibility (public, private, internal, and so on). In this case, C# is actually more complex than C++. The ref and out method parameter modifiers are an old, useful idea, and even more useful in a network environment. Network object marshaling code can use them to decide which objects to serialize and which to ignore.

Preprocessor

The C preprocessor was not included in Java because it was seen as an invitation to poor coding practice and an enormous source of bugs. C# includes a preprocessor essentially identical to that of C. Several preprocessors for Java are freely available for programmers addicted to this feature.

Native 'unsafe' code

One of C#'s most widely touted features is its direct integration of native code. Code blocks bearing the modifier unsafe can use C#'s pointer types to access unmanaged memory and platform-native resources. There is also a fixed keyword, used to "pin" an object to a specific address and protect it from the garbage collector. The word unsafe indicates to the compiler that the code being called uses memory pointers. While the C# specification targets performance as the reason for using unsafe code, it will probably be used more commonly for accessing the Win32 API and existing DLLs. The Java Native Interface (JNI) allows access to underlying system resources, but the Java language itself does not. JNI provides access through a software layer and in another language, usually C.

By this point, you have a good basic understanding of many C# features, which make it interesting and useful to Windows programmers. But the question remains: Why create this new language? Why not just integrate Java more closely with Windows or, even better, integrate Windows with Java? The next section addresses those questions.

The Standard Open Proprietary architecture

Microsoft has submitted C# to ECMA (European Computer Manufacturers Association), the European standards body that standardized ECMAScript. This is probably a thumb in the eye to Sun, which scrubbed Java standardization plans with both ECMA and ISO last year because of copyright concerns. (It remains to be seen how genuinely and successfully Microsoft will push for C# standardization.) These so-called standardizations of what are essentially proprietary technologies muddy the water for people doing real work in standardization development. True open standards are created in an open forum, with multiple parties providing input as the technology develops. Every high-tech company would like to be in the position of controlling an open proprietary architecture. To paraphrase Nixon aide Chuck Colson, if you've got customers by the architecture, their hearts and minds will follow.

Standards organizations should drive a hard bargain with companies who want to develop proprietary technologies behind closed doors and then come begging for "standardization" long after the time for meaningful community input has passed. Those that fail to do so risk becoming irrelevant repositories for vested interests instead of advocates for open systems and collaborative development. On the other hand, vendors can hardly be expected to contribute heavily to the success of their competitors' infrastructures. Consequently, standards organizations should accept proprietary technologies into their processes only if the originators of those technologies are willing to relinquish veto power over future development.

Standards are not open simply because their specifications are openly available (or, as in the case of ISO, available for a price). True open standards, like XML, are developed openly and collaboratively and often by competing interests. Those whose designs begin proprietarily become true open standards only when the technology originators have no special place at the table in the standards organization.

For example, Microsoft and Sun are both leaders in the development of XML technology, yet they will have to compete with everyone else on the basis of technical excellence, since the standard was developed in full public view. While other languages such as C and C++ were initially developed behind closed doors, the standards process effectively made them common property, in spirit if not in practice. The same cannot be said for Java, since Sun has retracted its bid for standardization. We'll see what ECMA will do about C#.

Closing remarks

If I were a Windows developer, I would be rejoicing at the creation of C#. It is much easier to use than C++, and yet is more full featured than Visual Basic. MFC programmers, in particular, should flock to this tool. It seems likely that C# will become a major language for developing under the Windows platform. Because of C# creator Anders Hejlsberg's excellent track record, I expect the language to live up to its promises, assuming that Microsoft delivers an implementation that does so. C# solves most of the same problems with C++ that Java solved five years ago, usually in the same way. C# also solves the business problems that Microsoft encountered when it found it could embrace and extend Java, but not extinguish it. And, if Microsoft marketing is to be believed, COM will finally be usable. C# itself is not particularly innovative: there is little in this language that has not been seen before. Still, its skillful combination of these well-understood features will provide good value to Windows programmers. Of course, those not wanting to limit themselves to Windows can still choose from among the many excellent implementations of Java for Windows.

Because of its lack of platform neutrality, C# is in no way a "Java killer." Even leaving aside Sun's five-year head start, and Java's successful capture of the "gorilla" (market-owning) position among enterprise server languages, C#'s Achilles' heel is that it is tied to Windows. Of course, in theory it isn't. But widespread cross-platform implementation of C# is like widespread multivendor implementation of Win32 and COM: possible, in theory.

High-technology consumers today, and especially IT managers, are appropriately wary of vendor lock-in. Encoding procedural information assets in a way that ties them to a particular vendor is a Faustian bargain. The Java platform is neutral with respect to operating systems. If you don't like the service you are getting from one vendor, or if your needs change, you can find another vendor that better meets your requirements. It will be some time before that can be said of C# or .Net. In short, while C# is a fine language for Windows programming, it will be able to compete with Java only when C# is freed from its Windows dependence. For the time being, C# users still won't get to decide where they're going today.

Acknowledgments

Many thanks to fellow ITworld.com author Michael Perry, who performed the technical review for this series, caught several potentially embarrassing mistakes for me, and tried his best to rein in my unruly opinions. Be sure to see Perry's article, as well as my discussion with him about C# versus Java, in Resources.

About the author

Mark Johnson is a writer, a consultant, and a JavaBeans columnist and XML guru at JavaWorld. His interests include design patterns, structured data representation, software architecture, enterprise data systems, and codeless software development. He is the president of elucify technical communications (etc), a Colorado-based corporation dedicated to clarifying novel or complex ideas through clear explanation and example. His client list currently includes Sun Microsystems, where he is a contract technical writer.
  • Print
  • Feedback

Resources