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

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.

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.

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

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.

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.

.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.

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.

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.

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

The built-in date/calendar functionality in Java is horrible compared to System.DateTime. There is a lot of info about this here: https://stackoverflow.com/questions/1969442/whats-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

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.

One thing that jumps out b/c it's on my interview list is that there is no "new" keyword analogue in Java for method hiding and there fore no compiler warning "you should put new here". Accidental method hiding when you meant to override leads to bugs.

(edit for example) Example, B derives from A (using C# syntax, Java behaves same way last I checked but does not emit compiler warning). Does A's foo get called, or B's foo? (A's gets called, probably surprising the dev who implemented B).

class A 
{
public void foo() {code}
}

class B:A
{
public void foo() {code}
}    

void SomeMethod()
{
A a = new B(); // variable's type is declared as A, but assigned to an object of B.
a.foo();
}

The most harrasing difference to me when I switch to java it's the string declaration.

in C# string (most of the time) in Java String

It's pretty simple, but trust me, it makes you lose so much time when you have the habit to s not S !

Java doesn't have LINQ and the documentation is hell. User interfaces in Java are a pain to develop, you lose all the good things Microsoft gave us (WPF, WCF, etc...) but get hard - to - use, hardly documented "APIs".

The one issue I've run into so far when working with Java coming from C# is Exceptions and Errors are different.

For example you cannot catch an out of memory error using catch(Exception e).

See the following for more details:

https://stackoverflow.com/questions/1888602/why-is-java-lang-outofmemoryerror-java-heap-space-not-caught">why-is-java-lang-outofmemoryerror-java-heap-space-not-caught</a>

It's been so long since I've been in Java but the things I noticed right off the bat in application development was C# event model, C# drag and drop vs using Layout Managers in Swing (if your doing App dev), and exception handling with Java making sure you catch an exception and C# not required.

In response to your very direct question in your title:

"C# developers learning Java, what are the biggest differences one may overlook?"

A: The fact that Java is considerably slower on Windows.