Chapter 3. .NET Languages

3. .NET Languages

The Common Language Runtime (CLR) is explicitly designed to support multiple languages. In general, though, languages built on the CLR tend to have a good deal in common. By defining a large set of core semantics, the CLR also defines a large part of a typical programming language built using it. For example, a substantial chunk of learning any CLR-based language is seeing how the standard types defined by the CLR are mapped into that language. You must also learn the language's syntax, of course, including the control structures the language provides. Yet once you know what the CLR offers, you're a long way down the path to learning any language built on top of it.

Understanding a CLR-based language starts with understanding the CLR

This chapter describes C# and Visual Basic (VB), the most important CLR-based languages. It also takes a brief look at C++/CLI, extensions that allow C++ developers to write CLR-based code. The goal is not to provide exhaustive coverage of every language featurethat would require three more booksbut rather to give you a sense of how these languages look and how they express the core functionality provided by the CLR. Throughout, the language versions described are those provided with Visual Studio 2005.

Perspective: What About Java for the .NET Framework?

From the beginning, Microsoft has provided J#, a version of the Java programming language for the .NET Framework. This language implements Java's syntax and behavior on top of the CLR. It's nice to have the option, but when does it really make sense to use J#?

There are two main situations when J# is the right choice. The first is when existing Java code needs to be moved to the .NET Framework. This code might have been created using Visual J++, Microsoft's pre-.NET Java tool, or a more mainstream Java tool such as Eclipse. In either case, the existence of J# makes it easier to port this code to the .NET world. It's important to realize, though, that the .NET Framework doesn't implement commonly used Java technologies such as Java Server Pages and Enterprise JavaBeans, so not all Java code can be easily ported. Still, typical Java business logic can be made to run on the .NET Framework without too much work. There's even a binary converter tool that can directly convert Java bytecode into MSIL, a useful thing to have if an application's source is no longer available.

The second situation in which J# might be a good language choice is when an experienced Java developer moves to the .NET Framework. People often feel an enormous attachment to their syntax, and so working in a familiar language might make the transition easier. Still, it's hard to argue that creating new .NET Framework code in Java is really a good thing. Microsoft is clearly focused on C# and VB as the main languages for building new .NET applications, and so there's some risk in choosing anything else. Also, the absence of standard Java packages in .NET means that this transitioning Java developer still won't feel completely at homethere's still a lot to learn. And given the strong similarities between Java and C#, even the biggest Java fan shouldn't be too upset at switching to C# instead.

Microsoft's Java support is clearly focused on migrating code and developers to the .NET Framework, rather than on helping developers create great new software in Java. The battle lines are clear: It's .NET vs. the Java world. This is unquestionably a good thing. Having two powerful technology camps, each with a strong position, is the ideal world. Each provides innovations that the other can learn from, and in the end, the competition benefits everyone.