I'm not ashamed to say it... C#
is my favorite programming language these days. It wasn't always so. In fact, I didn't pay a lot of attention to the C# programming language when Microsoft first introduced it in 2000, mainly because I initially looked at it as being essentially Microsoft's attempt at an alternative to Java.
It's Really Just "Microsoft Java" Isn't It?
Yeah. Kind of.
Well... no, not really. But it's easy to think that if you don't look too close.
In the early days of C# this was a common question, and it was fueled at least in part to the fact that Java creator James Gosling
referred to C# as an "imitation" of Java. As I said above, I have to admit that's how I thought of it initially myself.
In terms of the basic language syntax, C# is pretty darn similar to Java. And yes, the combination of C# and the .NET framework is in some ways similar in concept to the Java language and runtime environment, albeit perhaps more in the early days than now. However, as I've become more experienced with both environments over the years, I've become more and more aware of the differences, and they can be pretty significant. I've come to the conclusion that C# is no more an "imitation" of Java than Java is an imitation of C++. They have similar design goals in many respects, and a similar heritage, so of course they're going to be pretty similar. But ultimately, C# and Java are really more like close cousins than twins.
The Real Microsoft Java
When Sun Microsystems released Java in 1995, it seemed like a very interesting new language and it got a lot of attention in the computer industry press as well as in the mainstream. However, it simply didn't seem like it applied to any of the projects I was doing at the time. I ended up writing a few goofy little applets for one of my websites, but that was about it.
Sun told the world that Java was free for everybody to use, so a few years later, Microsoft came out with their own implementation of Java called J++ which used Microsoft's own virtual machine and runtime support. To nobody's great surprise, Microsoft's runtime was different from Sun's in that it facilitated the use of Microsoft technologies like Active-X
. And Microsoft's J/Direct
framework gave the J++ code access to the underlying Windows API, bypassing Sun's class libraries.
Microsoft wanted to position J++ as a way to use the Java language for Windows-specific development, but that idea didn't sit very well with Sun. Their philosophy was that Java should always be as platform-independent as possible and they felt that Microsoft's efforts, should they succeed, would end up making developers and their code dependent on Microsoft's platform and tools.
Despite Java being free, Sun had kept a very tight grip on how it was supposed to work, and they claimed Microsoft wasn't playing by the rules. In particular, in order to use Sun's "Java" trademark in any fashion, all implementations were required to be 100% compatible, and Microsoft's version of the runtime didn't pass Sun's Java validation tests.
Lawsuits... many lawsuits.
Scratch J++, Enter C#
At the start of 1999, the lawsuits over J++ were still going, but Microsoft was losing ground. Java had gained popularity, but few developers were doing much with J++. It wasn't the big success that Microsoft had hoped.
No doubt there were also many web developers who simply agreed with Sun's philosophy regarding cross platform compatibility, but it was thought by many that the compatibility problems were introduced deliberately because Microsoft wanted to kill the Java platform. That first part was never established in court, but there was plenty of evidence for the second part.
Meanwhile, Microsoft had been working on a new system frameworks they were calling Next Generation Windows Services.
The new frameworks which would ultimately be known as ".NET". You may have heard of it.
At the heart of the new system was the Common Language Runtime (CLR), a new virtual machine that was responsible for running .NET programs. One of the major design considerations of the CLR was avoiding many of the common flaws found with existing programming languages, so that meant that new compilers would be needed. Microsoft launched the "Cool" project at the start of 1999. Cool
was designed to be a managed language that would follow the general example of C and C++ syntax. In fact, the project name stood for "C-Link Object Oriented Language".
Because of trademark issues, the "Cool" language was later renamed to C#.
When Microsoft first started talking about the .NET
framework, the name had many people thinking that it was a web-only thing, and I have to admit that was my own first impression. The use of a virtual machine sparked comparisons with Java, and when the new C# language was added to the discussion, it looked like Microsoft was trying to redo J++ in a way that didn't rely on Sun for anything.
In truth, however, the use of a virtual machine was a tried and true technique that Microsoft had been using for years before anybody ever heard of Java. The development of .NET, C# and the new Common Language Runtime (CLR) had a broader scope and much bigger goals than being a Java knock-off. If you want to learn more, check out this interview
with the creator of C#, Anders Hejlsberg
, and this one too
Switching From C++
Despite my misgiving about finding a use for C#, I bought one of the first books released to learn more about it. As I dug deeper, it became clear that the language actually had a number of significant differences from Java.
However, it wasn't clear that the likely applications of C# were much different, and because the .NET runtime was still in beta, the whole thing just didn't really seem like it was ready for prime time quite yet. So I waited.
At that point in time, my Windows-based programming was mostly centered around creating and maintaining GUI-based desktop applications and command-line utilities, using Visual C++ and the Microsoft Foundation Classes (MFC). I had been using VC++ and MFC since they were first released and was very comfortable with the environment.
However, I wasn't completely happy
with the VC++/MFC environment in some respects, which is why I had my eye out for alternatives.
The first problem was that any project I did with MFC seemed to have memory leaks. Not necessarily hugely significant ones, but every time I ran a program under the debugger, I would get a length report at the end about memory issues. The first few times I saw this, I spent a lot of time trying to find the cause in the debugger. Eventually I discovered the problem would occur even with code that was generated entirely by Visual Studio, so it was apparently something with the MFC libraries and not my code.
That didn't really make me feel better.
When C# was included in the Visual Studio 2002
release, the .NET framework was far more mature, and its usefulness was
more and more apparent. It
had things like a regular expressions library that was missing from the standard VC++/MFC setup, to name one example. Eventually I started adding calls into the .NET framework from my C++ projects. The VC++ interface to accessing managed code in the .NET framework was a bit clunky, but it worked.
I still hadn't found a use for C#, however.
Along the way, I finally had some projects where Java was called for, because of a need for cross-platform compatibility. Then it finally happened... a new project where I could use C#.
I had a legacy project done with Visual C++ and MFC that needed to be updated to access a SQL Server database across the local network instead of reading and writing data files. The program needed to be able to run on multiple stations at once and share data between them.
I got it working, but I really wasn't very happy with the way that the database stuff worked. To be fair, some of that was due to the way the database support got bolted onto the existing project, but I didn't really care for the way the API was setup either.
After the update was finished, the client had a brand new list full of new features they wanted to implement in the application, and they also wanted to create a new website that accessed the same database. Maintaining the existing C++ project and adding the new features was doable, but when the website idea was thrown into the mix, it didn't look like a good idea. We decided to redo the application in C# and use ASP.NET for the website. A lot of the existing C++ code could go into the new version without much change, but things like the database code could be drastically improved by the rewrite and then shared between the two projects.
I was much happier with the way the database connectivity worked in C# and .NET, but writing the database code in C# only for the website and maintaining that in parallel with the C++ code for the application would have been twice as much work overall.
As I started the new C# version of the application, my initial concern was making the transition from using MFC with Visual C++ for the user interface design and coding. Especially since the client wanted the existing user interface to stay pretty much the same. The first thing I had to decide was if I should use Windows Forms or Windows Presentation Foundation (WPF) for the user interface.
Windows Forms had been around for awhile, and most of the books I'd read about C# had used it for whatever GUI samples they might have. In fact, I'd recently bought a pretty decent book that focused entirely on it. (Windows Forms 2.0 Programming
) That was a big plus.
At the time, Microsoft had only just released the first version of Windows Presentation Foundation and there weren't a lot of books or other information about it yet. It looked like it had more power and flexibility overall, but also like it would take more time to learn.
Since I was mostly replicating the existing MFC-based GUI I decided to go with Windows Forms. The GUI creation tools for Windows Forms were a lot like the Java Swing GUI builder tool in the Net Beans or Eclipse IDEs, which I had recently become familiar with. It turned out that it was very easy to make the transition and it really didn't take me very long before I was more productive than I'd ever been with MFC.
So How Is C# Different From Java?
I'm not going to make an attempt to enumerate a list here, nor try to keep track of which version of C# versus what version of Java is being discussed, and so forth. Rather I'm going to try to cover some of the basic differences.
First, I would have to say that Java is arguably more concerned with keeping developers out of trouble at all costs than is C#. A good example of this is the way that C# allows you to mark off a block of code as "unsafe".
Normally in C#, using C-language style pointers and related pointer operations is not permitted, just as in Java. Much of the time this is not an issue, but there are times when you just have no choice, so C# allows use of the unsafe
keyword. By marking a function or code block as "unsafe", you're permitted to use C-style pointers and pointer operations on memory.
Under the right circumstances, this allows you to do certain things much, much faster than would be the case with "safe" code. Perhaps most importantly, you don't have to use a different compiler or programming environment to write, compile, and possibly debug what might be no more than a few lines of code. You can do all that within the main project and go back and forth between the "unsafe" code and the rest of the project pretty seamlessly.
The requirement of placing such code in an "unsafe" block means programmers are much less likely to do something wrong accidentally, but it's a relatively easy thing to do when you need it. Not so with Java. To do something functionally like an "unsafe" block would require you to write code in another language like C, compile it, and then tell your Java project where to find it. After all that, then your Java code could call that external function via the Java Native Interface (JNI).
It's a lot of steps, involves extra tools, and it's a sufficient pain in the butt that most Java programmers don't do it unless they expect a rather substantial difference in performance or unless they simply have no other choice.
Surprisingly, there are some rather significant items for which C# and .NET languages in general don't play quite so nicely with. It's not always a huge problem, but there are things which require the programmer to jump through a few extra hoops to access WIN32 calls or to use 3rd party tools because Microsoft has not made them accessible directly via .NET.
, the game programming API, is perhaps the biggest example. The lack of a managed version of DirectX means that if you want to write a game for the Windows 8 app store, for example, you have to do it using Visual C++ instead of C#. Officially, anyway.
Although there was supposed to be an official Microsoft managed version of DirectX at one point, that project seems to have disappeared. Instead, we have a couple of open source projects like SharpDX
which provide access to DirectX.