C# developers learning Java, what are the biggest differences one may overlook? [closed]

Question

For c# developers that are staring out to learn Java, are there any big underlying differences between the two languages that should be pointed out?

Maybe some people may assume things to be the same, but there are some import aspects that shouldn't be overlooked? (or you can really screw up!)

Maybe in terms of OOP constructs, the way GC works, references, deployment related, etc.

Answer 1

A few gotchas off the top of my head:

• Java doesn't have custom value types (structs) so don't bother looking for them
• Java enums are very different to the "named numbers" approach of C#; they're more OO. They can be used to great effect, if you're careful.
• byte is signed in Java (unfortunately)
• In C#, instance variable initializers run before the base class constructor does; in Java they run after it does (i.e. just before the constructor body in "this" class)
• In C# methods are sealed by default. In Java they're virtual by default.
• The default access modifier in C# is always "the most restrictive access available in the current context"; in Java it's "package" access. (It's worth reading up on the particular access modifiers in Java.)
• Nested types in Java and C# work somewhat differently; in particular they have different access restrictions, and unless you declare the nested type to be static it will have an implicit reference to an instance of the containing class.

Answer 2

here is a very comprehensive comparison of the 2 languages:

http://www.25hoursaday.com/CsharpVsJava.html

Added: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp

Answer 3

I am surprised that no one has mentioned properties, something quite fundamental in C# but absent in Java. C# 3 and above has automatically implemented properties as well. In Java you have to use GetX/SetX type methods.

Another obvious difference is LINQ and lambda expressions in C# 3 absent in Java.

There are a few other simple but useful things missing from Java like verbatim strings (@""), operator overloading, iterators using yield and pre processor are missing in Java as well.

One of my personal favourites in C# is that namespace names don't have to follow the physical directory structure. I really like this flexibility.

Answer 4

There are a lot of differences, but these come to mind for me:

• Lack of operator overloading in Java. Watch your instance.Equals(instance2) versus instance == instance2 (especially w/strings).
• Get used to interfaces NOT being prefixed with an I. Often you see namespaces or classes suffixed with Impl instead.
• Double checked locking doesn't work because of the Java memory model.
• You can import static methods without prefixing them with the class name, which is very useful in certain cases (DSLs).
• Switch statements in Java don't require a default, and you can't use strings as case labels (IIRC).
• Java generics will anger you. Java generics don't exist at runtime (at least in 1.5), they're a compiler trick, which causes problems if you want to do reflection on the generic types.

Answer 5

.NET has reified generics; Java has erased generics.

The difference is this: if you have an ArrayList<String> object, in .NET, you can tell (at runtime) that the object has type ArrayList<String>, whereas in Java, at runtime, the object is of type ArrayList; the String part is lost. If you put in non-String objects into the ArrayList, the system can't enforce that, and you'll only know about it after you try to extract the item out, and the cast fails.

Answer 6

One thing I miss in C# from Java is the forced handling of checked exceptions. In C# is it far to common that one is unaware of the exceptions a method may throw and you're at the mercy of the documentation or testing to discover them. Not so in Java with checked exceptions.

Answer 7

Java has autoboxing for primitives rather than value types, so although System.Int32[] is an array of values in C#, Integer[] is an array of references to Integer objects, and as such not suitable for higher performance calculations.

Answer 8

No delegates or events - you have to use interfaces. Fortunately, you can create classes and interface implementations inline, so this isn't such a big deal

Answer 9

The built-in date/calendar functionality in Java is horrible compared to System.DateTime. There is a lot of info about this here: What's wrong with Java Date & Time API?

Some of these can be gotchas for a C# developer:

• The Java Date class is mutable which can make returning and passing dates around dangerous.
• Most of the java.util.Date constructors are deprecated. Simply instantiating a date is pretty verbose.
• I have never gotten the java.util.Date class to interoperate well with web services. In most cases the dates on either side were wildly transformed into some other date & time.

---

Additionally, Java doesn't have all the same features that the GAC and strongly-named assemblies bring. Jar Hell is the term for what can go wrong when linking/referencing external libraries.

As far as packaging/deployment is concerned:

• it can be difficult to package up web applications in an EAR/WAR format that actually install and run in several different application servers (Glassfish, Websphere, etc).
• deploying your Java app as a Windows service takes a lot more effort than in C#. Most of the recommendations I got for this involved a non-free 3rd party library
• application configuration isn't nearly as easy as including an app.config file in your project. There is a java.util.Properties class, but it isn't as robust and finding the right spot to drop your .properties file can be confusing

Answer 10

There are no delegates in Java. Therefore, aside from all the benefits that delegates bring to the table, events work differently too. Instead of just hooking up a method, you need to implement an interface and attach that instead.