Home > .Net / C#, Java > C# or Java – Which one is better ?

C# or Java – Which one is better ?

August 5th, 2013 Leave a comment Go to comments

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 ?

You know what, just check them hereI’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. 


Like the article ? Share it ! ;)

  1. Steven Koehler
    September 22nd, 2013 at 17:54 | #1

    For Reason #7, Java does offer something similar to the C# using statement. Available with Java 7 is the try with resources statement: 

    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();


  2. September 22nd, 2013 at 19:10 | #2

    Hi Steve, 

    Great note, you are right. My experience in Java is with version 5 and that's the reason for the inaccuracy. 

    Thanks ;)

  3. vdb
    September 27th, 2013 at 05:02 | #3

    #1 – very true. it is so frustrating to work with numerous framework.

  4. Breaking Floor
    October 2nd, 2013 at 10:12 | #4

    For Reason #2

    I don't think ArrayList<int> in Java would compile in the first place, however ArrayList<Integer> would pass in Java.

  5. October 7th, 2013 at 21:16 | #5

    Yep, you are absolutely correct. I've been working with C# for some time now where you actually can pass int (which is a structure there) as a generic parameter. 

    Thanks ;)

  6. Net
    October 12th, 2013 at 18:45 | #6

    java is neck-deep in shit

  7. Breaking Floor
    October 13th, 2013 at 01:09 | #7

    Haha, why would you say that?@Net

  8. Net
    October 17th, 2013 at 21:22 | #8

    @Breaking Floor
    that’s obvious :)

  9. Bukes
    November 11th, 2013 at 13:47 | #9

    C# – write once, use anywhere
    Jave – write once, run away

  10. C# is Java done right
    January 27th, 2014 at 23:22 | #10

    C# primitives actually fit nicely into their type system, as opposed to Java’s which require hideous code to do anything…compared two Integer objects recently? Have a guess does 1==1? It depends! But greater/lesser than comparisons work properly! What fun!

  11. max
    March 6th, 2014 at 08:41 | #11

    Yes bro, you said all. As a PHP developer struggling to pick the next language, your post has really shined a light on the write part as time is a scarce and valuable resource. Keep up the good work bro. thanks

  12. xYan
    March 6th, 2014 at 23:55 | #12

    Xmm. That’s why android runs on c# i guess?! C# write once run anywhere? Give me a break @Bukes.

  13. Sam
    March 21st, 2014 at 00:46 | #13

    Err C# write once run anywhere? Is that anywhere provided it’s windows.. that awful bug-ridden, full of security holes platform?

  14. September 23rd, 2014 at 13:28 | #14

    Really nice guide. I’ve been thinking of doing either Java, C# or JavaScript/HTML5 for a while now. I think I will go with C#, but I’m still a bit interested in JavaScript as well. The only problem is that I don’t have time doing both of them.

  15. Harsh
    March 1st, 2015 at 11:35 | #15

    Many of this problems are solved by Scala
    Which is an JVM implementation
    And Java is very fuzzy, I mean very but on contrary Scala is awesome alternative not just for prototyping but for production server as well.
    Also much better asynchronous and concurrency then c# at any point of time.

  16. Sam
    February 25th, 2017 at 16:13 | #16

    How about C#’s structs? Allowing the programmer to define their own value types is really useful, especially in array iteration (can have substantial increase in performance)

  17. April 26th, 2018 at 09:03 | #17

    The top features are researched and found that most of the Java developers fail to see in C#. Clear benefits to Java users are offered by few of them while few of them are surrounded by controversy.

  18. July 25th, 2018 at 09:09 | #18

    The way you have differencate between java and c# is very interesting and helpful for me in my work.Thanks for posting your article.Looking forward for more articles by you.
    Thnaks a lot.

  19. Lighty
    November 21st, 2018 at 03:39 | #19

    Dunno but I have been considering learning C# lately, seems like Visual Studio Code and .Net Core is the future.

  1. No trackbacks yet.

Copyright © Developing the future 2013. Licensed under the CC> BY-NC-ND 3.0 Creative Commons license.       
Audi R8 wallpapers Sony Xperia Z4 Tablet WiFi