Posted by: jsonmez | February 1, 2010

C# vs Java Part 1: The Languages

I have been long contemplating this post, because I think it is a very important topic, but I have also lamented writing it do to the controversial nature of the subject and fearing that I would not be as accurate in my portrayal as deserved.  Nevertheless, I am going to attempt to cover selective parts of this subject in a several part post.

A little bit of preamble before I begin getting into the language differences:

  • When I am comparing C# to Java, I am also comparing the platforms.  .NET framework and the CLR are as much part of C# as the JVM and Java EE stack are part of Java.
  • I am covering this topic from the perspective of a developer and architect working with both of these technologies.  The perspective is from my personal perspective, from my experience.  I do not see it fit to rehash much of the information that already exists comparing the languages and platforms from an academic or religious viewpoint, instead I seek to compare the languages and platform from an “in the trenches, personal experience” viewpoint.
  • This is not intended to be comprehensive by any means.  I don’t know everything about .NET and I don’t know everything about Java.
  • While I have my personal preference, I am neither religious about the subject, nor do I intend to force the choosing of “sides”.  What I do intend is to be as objective as possible and encourage and open-minded view where learning can be had from both sides.

There really isn’t much difference in the basic syntax of the two languages.  For the most part on a basic level, writing algorithms and designing classes in both languages looks pretty close to the same.


One of the first major differences I noticed when starting some work on a Java project, from primarily working in C#, was the ability to anonymously subclass a class on object creation and override it’s methods.  While I am generally against concrete inheritance, this Java language feature is very convenient for unit testing legacy code without requiring large refactors.  Here is an example:

LegacyClass legacy = new LegacyClass()
   public void createConcreteDependency()
      return mock;

What is happening in this snippet is that I am anonymously inheriting from LegacyClass and providing an override for a method that created a concrete dependency.  C# doesn’t really have a way to specifically do this, which normally isn’t a problem, but when unit testing legacy code it can be very useful.

On the other hand C# allows partial classes.  Which is something I really wanted when working on some code generation work in Java.  With C# you can define a class across multiple files.  The real use of this is when you are generating code and you want to be able to have part of a class generated, but still have the other part of the class manually controlled and versioned.

I’ll mention C#’s properties here, even though they can also be in the “Syntactic Sugar” section.    C# properties essentially do what manually created getters and setters do in Java.  I am not 100% convinced this is a good thing, but I will say it is useful.  There is a strong argument that you should never write getters and setters, because they almost always violate data hiding.  I am not in that camp yet, but I am leaning towards it more.  Anyway, without going too far off topic,  the property feature is very nice to have when you want it.  When working in Java code I often expect to be able to just set something that I think should be a property and then I have to remember, “oh yeah, Java.”

Another important difference is that Java methods in classes are automatically virtual.  In C# only methods with the virtual keyword are virtual.  Although this isn’t a big difference in design, I prefer not having something virtual unless I intend for it to be allowed to be overridden as opposed to having it default to virtual.

All in all, besides these differences, Java and C# classes are pretty similar.  There is the whole inner class difference, but really you shouldn’t be using inner classes.  Yes, I know there are specific situations when they are useful, but for the most part in day to day programming they aren’t and shouldn’t be used.


I have to say, I love the Java enumeration.  The ability to add some functionality to an enumeration is really very useful.  Java made enumerations just like classes, (except they can’t extend another class.)  C# enumerations are more along the lines of C/C++ implementations in which they are just basically integers.

I use enumerations very often in my code.  I find that restricting the set of options that can be passed into a method, makes the understanding that method more clear, and reduces complexity in the system.  The right place for the logic that goes along with an enumeration is in the enumeration.  Java gets this one right.

My Big Beef: Function Pointers

I have long lamented not being able to remove a bunch of if/else conditions in Java with a map which maps a condition to function pointer.  I will use the term “function pointer” here instead of delegate or closure.  (Yes, I know all 3 are different.)  Really what I am trying to achieve when I refer to function pointer, is finding a way to reference a method I want to call in Java without having to use the observer pattern.

C# handles this with delegates and an eventing framework.  C# has expanded on this to the point where you don’t even realize you are using function pointers.  First, there were anonymous delegates, then there were Lambda expressions.  This is where C# really shines.  Lambda expressions allow a C# programmer to very succinctly express code as data and operate on it in that fashion.  Here is an example:

int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

int oddNumbers = numbers.Count(n => n % 2 == 1);

There is just something magic about writing your first Lambda expression and having intellisense list your options inside code that looks like the compiler couldn’t possibly know what the types are.

For you functional programming buffs, this isn’t a big deal, but for us OOs it is amazing.  I strongly believe Lambda expressions have the potential to completely change the way we think about programming algorithms and actually take them to a higher level of abstraction, much like the combination of collections and generics did.

I know that Java is supposed to get some form of closures in JDK7, but until it does, this is going to be a major weakness.  Having worked through many programming problems in both languages, I can tell you that Lambda expressions can greatly simplify the expression and solution of a problem.

To Be Continued…

I don’t want to write anything longer than I would want to read at one time.  For that reason, I will cover more on language, including Generics, Exceptions, and Syntactic Sugar differences in C# vs. Java tomorrow.



  1. Great post, John! I heard about your blog from the Stack Overflow podcast question. I read through all of your articles! Interesting stuff, keep it up!

    • Thanks, I appreciate the comment!

  2. […] Making the Complex Simple Software Development from John Sonmez's Perspective « C# vs Java Part 1: The Languages […]

  3. […] C# vs Java Part 1: The Languages – John Sonmez begins a series of posts providing a comparison between C# and Java taking into account both the language differences and the underlying frameworks and virtual machines. This post is continued in the second half of part 1 C# vs Java Part 1: The Languages (Continued) […]

  4. I would suggest comparing C# to a newer JVM language, say Scala, and seeing the differences. Java hasn’t moved as fast as C# so the comparison isn’t as interesting as with a newer JVM language. I would definitely be interested in the comparison between C# and Scala.

    Here is the Scala code for the filtering and counting.

    val numbers = Array(5, 4, 1, 3, 9, 8, 6, 7, 2, 0)
    val oddNumbers = numbers.filter(n => n % 2 == 1).length

    or shorter using an anonymous variable in place of ‘n’:

    val oddNumbers = numbers.filter(_ % 2 == 1).length

    • I will have to look into Scala more, I haven’t really looked at it much at all. Perhaps I’ll do a post once I have given Scala a try. Thanks for pointing this out.

  5. One thing to bear in mind about C#’s properties is that they have additional meaning to them over a public variable or getters and setters.

    The way almost all properties I’ve seen are saying “Oi, here is a bit of information in this class that you might want to look at.” One (bad) example is autobinding properties of IEnumerable to a DataGridView.

    Java doesn’t have this. getAddress() might be returning a “property” of the class address or an address object to be messed with or or or… Having a property means more than just a method or a variable.

  6. […] C# vs Java Part 1: The Languages […]

  7. […] C# vs Java Part 1: Language […]

  8. […] C# vs Java Part 1: Language […]

  9. Visit
    You’ll find a new Stab language for Java with c# syntax. It’ in beta2.


  10. Sounds like an interesting article; maybe I will find some time to read it.
    There is a little (minor yet annoying) difference also described in my article:

  11. […] that might not be any big revelation to you.  The languages are pretty close already in syntax, but I have found this principal extends much further than […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: