• Tweet

• Tweet

Why C# vs Java ?

Back in the days before my first job, I’d had one basic decision to make. I needed to choose a programming language to start with and, honestly, it sounded like a really important one. When you are young and without any experience, it’s very easy to get confused with all these strange acronyms, all the programming languages, platforms, technologies. Which is better, which is faster, easier or harder to learn.

Well, for my first job I chose to learn Java. Maybe partly due to the fact that I was big fan of Linux and the open-source community at that time, and Java seemed like a nice non-commercial alternative to any Microsoft technology.

Right now, 8 years later, I strongly recommend using C# instead of Java. Let me tell you why.  

 

In general

At the surface, C# and Java are not so different. They are both from the C-language family and share a common syntax with C and C++. You will hardly find any differences in the basic control flow structures, variable declaration, etc. The higher-level constructs are a little bit different, but the basic principles are the same: polymorphism and late binding, class encapsulation, class inheritance – there are minor differences and it’ll generally not took you long to get used to it.

However, the reasons why I would choose C# over Java for most of my current projects are more important and have a significant impact in the general development lifecycle.

 

Why I will not choose Java over C# for the majority of projects right now

By importance:

Reason #1: The tremendous amount of frameworks/libraries

You know there are times when you just want to change your job. Let’s say you’ve been working as a senior Java enterprise developer for the last 5 years, and you want to change the atmosphere, the surroundings, maybe to get a better salary. So you go in your favourite job seeking site and start searching for Java EE Developer offers. Good, there are a lot of available positions right now.  

But do you know what ? You will most probably not fit in the majority of them. Because there are tens of Java EE platforms, and every one of them is different enough. For example, which technology exactly would you choose for your backend ?

• JSP/Servlets
• JSF (RichFaces, ICEFaces, PrimeFaces, ADF Faces, MyFaces ?)
• Spring
• Struts
• GWT
• Wicket
• Netty
• Seam
• Sitemesh
• Tapestry
• Play

You know what, just check them here. I’m sure there are more of them.

Which basically means you are screwed. Get ready to learn a new framework for every job out there, and don’t get fooled by the general Java EE Developer title of the job description. And no, it is not easy to learn a new framework. And no, it’s not related to how smart you are.

And it’s even worse for the people who are trying to hire developers with the exact skillset. They often end up with making compromises with the candidate’s experience, leading to slowdowns, irritation and ugly pattern mix-up.

 

Reason #2: There are no generics in Java.

You think Java has generics ? Well it doesn’t, what you get is simply a syntactic sugar. No performance benefits, simply boxing/unboxing. Ugly casts, speed consuming.

What do you think happens when you write ArrayList<Integer> in Java. A new class is generated with the right parameter ? Nope. The compiler takes away the type parameter and substitutes it with Object everywhere, erasing all type information. And that is why, if you have ever wondered, you don’t have full debug information for generic lists in your favourite IDE. But the compiler includes all the casts for your, effectively performing boxing/unboxing every time you access your list.

So you get the syntactic sugar, but you don’t get any performance out of it.

I’m not going to discuss all of this here in details, I already have, so feel free to check my article on Differences between generics in Java, C# and C++.

 

Reason #3: There are no anonymous functions in Java

There are no anonymous functions in Java. If you need similar functionality, you can always use anonymous classes. These can be defined like this:

    button.addActionListener(new ActionListener() {
 
    public void actionPerformed(ActionEvent e)
    {
        // do something.
    }

This will instantiate an automatically generate a subclass of ActionListener (or to be more precise, a class that implements ActionListener), which is an interface. Which leads us to the next point, which is…

 

Reason #4: No delegates. No semi-functional programming.

In Java, you don’t have delegates. If fact, the only way to mimic the delegate behavior is by instantiating an anonymous class and defining a method inside. Quite ingenious. And it’s the actual way used in Swing, for example, which allows us to attach actions to events. You already saw how to define an action listener in Swing.

In C#, the anonymous functions are closely related to the delegates. We even use the delegate keyword to define the, for example:

TestDelegate testDelB = delegate(string s) { Console.WriteLine(s); };

And to make it even more concise, we can use a lambda expression:

TestDelegate testDelC = (x) => { Console.WriteLine(x); };

Which leads us to the next closely related point…

 

Reason #5: No Lambda Expressions. No LINQ.

Well, that’s a big reason. The Language Integrated Query (LINQ) is great, it lets you look at your data structures as if they were tables and perform queries against them. You have LINQ to Objects, LINQ to SQL, LINQ to XML… and you can always create a provider for your custom data structure. The lack of anonymous functions, pointers to methods and extension methods is in a direct relation to this one.

The lambda expressions are simply means to make LINQ more elegant and concise. In conjunction to the extension methods, which are a great alternative to simply inheriting classes or using different patterns to extend behaviour, you are given a very powerful tool to make your code even more powerful.

 

Reason #6: Forget about Windows-related development.

According to Wikipedia, Windows takes over 80% (!) percent of the market concerning the average user. Why would someone want to create a desktop app with Swing, when he has WinForms and WPF (which is great by the way, but the learning curve is really steep) ? What if you want integration with other Windows-related services, like Active Directory, for example ? If your target user base is Windows users, the choice is clear.

I will skip discussing WinRT, which is entirely different thing.

 

Reason #7: The small differences

From a syntactical point of view, C# has a lot of small but important improvements. Few of them:

• Properties instead of Getters/Setters. 
  This means native support for this encapsulation improvement, automatic properties, etc.
   
• The using statement. 
  It allows us to automatically dispose unused objects (via a Dispose() method, this is not the same as using a destructor), which ensures us that any related resources will be deleted in time.
   
• Destructors.
  Yes, in C# you can define destructors, although it’s not a very common practice. And yes, it can be important part of resolving some memory-management issues and more.
   
• Pointers.
  In C# you can work with pointers, when the need arises. You can manually allocate and deallocate memory for maximum control.
   
• Dynamic variables.
  Don’t know the exact type at compile time ? You can use dynamic variables if you absolutely need to. This is a reference to the loosely-typed languages like PHP and JavaScript.
   
• The var keyword.
  It allows the compiler to automatically infer the type on the right of the assignment operator. This way you are not obligated to write down the full name of the class in use.
   
• The yield keyword.
  More elegant enumeration over enumerable types with the yield keyword. Aside from the obvious syntactic sugar, you also get speed benefits.​
   
• No checked exceptions.
  Leads to more clean code, although you can argue if you like.
   
• Operator overloading.
  Yes, you know that from C++. And yes, it is cool.
   
• Decimal type.
  12 bytes at your disposal.
   
• Indexes.
  If you want your custom enumeration type to behave like an array, you can implement it.
   
• The Readonly keyword. 
  Aside from the standard const field. This is basically a hybrid between the two but comes very handy especially when working with more than one dynamic libraries.
   
• Extension methods.
  Can’t use inheritance ? Don’t want decorators ? Use extension methods. It’s one of the basic techniques used in LINQ.
   
• Events.
  Basically a syntactic sugar that will make your life working with delegates a little bit more pleasant and safer.

Et cetera.

 

Reason #8: C# is not .Net

Meaning that C# is only one of the supported languages by the .Net platform. There are other interesting alternatives like J# (Java), IronRuby (Ruby), IronPython, IronLisp and, of course, Visual Basic. These languages inherit most of the features I already discussed, but it’s a question of preference. I will, however, recommend using C# whenever possible.

And although I use C# extensively in my development, I can’t neglect the possibility of using various syntax of different languages for Microsoft development.

You can find a full list of the CLI supported languages here. 

 

Reason #8: Using .Net is possible on Linux without emulation

With a project called Mono, which is an open-source implementation of the .Net framework. Although it’s not a reason for me, because I don’t have any development experience over Linux, it might be a nice argument for someone who thinks about Java vs C# programming on a Linux distribution.

I don’t know if this project is mature enough, I don’t know if it’s buggy or stable, feel free to find out more on Mono’s official website.

 

In Conclusion

The truth is that Java is still there, it is actively used and it is not going to die soon. Java is mature and reliable and the majority of enterprise-scale products use exactly Java for their core systems. Java is not dead and is still actively used in the majority of enterprise projects. So take your time. 
 

---

 

Google+