Monday, 21 March 2011

Java vs C#

Java platform Pros

  • Fully cross platform APIs including support for Graphics, Windowing and Multimedia.  All future APIs will be cross platform.  Java has even more APIs than Windows.  Look at the current proposals
  • Mature.
  • LOTS AND LOTS of libraries available.  Many are free and/or open source.
  • High density of OO design patterns put to practise compared to C#/.NET.  This makes developing complex applications much easier (at the cost of making 'my first text editor' type projects slightly more difficult).
  • Well designed APIs following good OO practise.
  • The Java Community Process allows people with an investment in Java have a say.  New Java features can be proposed, discussed and voted for in a open democratic forum.  Microsoft does NOT have anything like this which is unfortunate for anyone investing in .NET.
  • Apache.
  • Currently supported by multiple commercial vendors (not one).
  • Although not recognised by any international standards committee, Java is an open standard governed by Sun and the JCP members (or which there are MANY).  C# is an ECMA standard but without support from Microsoft, very few third parties have been willing to implement it.  Sun also tends to be less secretive than Microsoft about their products.  The C#/CLI ECMA submission is also just a subset of the .NET framework.  It has yet to be seen whether any future APIs for .NET will ever be submitted for standardisation (it doesn't look good).
  • Smallest unit of distribution is a class (.class file).  This helps in application development, debugging and deployment.  Having a one to one mapping between types and the file system is simpler because file systems are well understood.
  • Good IDEs are available (NetbeansEclipseTogether).  Many are free and support more features than VS.NET.  Unfortunately many are slower than VS.NET :(.
  • Swing is well designed and utilises the MVC design pattern extensively.  Windows Forms pales in comparison.
  • Swing is more powerful than SWF(System.Windows.Forms).  For example, border styles can be plugged into any component using the strategy design pattern.  In Windows Forms, components are responsible for supplying and drawing their own borders.  Some support borders, some don't, and some only supply a few borders.  This is because SWF is a thin wrapper around 7 year old windows controls and doesn't seem to have any improvements over WFC in J++.  Infact it's lacking some features that were present in WFC like DHTML support.
  • Java developers are more likely to be University graduates with a strong understanding of OOP.
  • Unlike Microsoft, Sun understands and embraces OOP.  Microsoft prefers speed over good design (at least some of their employees seem to anyway).
C#/.Net Pros

  • The CLR is well designed and arguably better than the JVM (pity about some of the class library...) .
  • The CLR supports execution of both managed and unmanaged code.
  • The CLR was designed to be language agnostic and has extended instructions to support non-imperative languages such as mondrian (a functional language) and mercury (a logical language).  Ironically, Java currently supports more programming languages.
  • The best way to write Windows desktop and web applications.
  • The remoting framework is advanced and well designed.
  • Good support for taking advantage of the native OS.  [This isn't so good if you want to be cross-platform].
  • Metadata attributes are a VERY, VERY powerful feature.  Attributes allow classes to be much more expressive.  Java NEEEEEDS attributes.
  • SWF is faster than Swing (most of the time).  Unfortunately the design is lacking when compared to Swing.  My guess is it was designed with VB programmers in mind :-(. Windows Forms does have powerful support for DataBinding.  If you're writing data bound rich clients, Windows Forms will get the job done quicker.
  • The proposed generics support is vastly superior to the upcoming Java 1.5 implementation.
  • XML documentation tags are cool.  (We have JavaDoc tags to thank for promoting the idea).
  • The CLI is an ECMA standard.  Unfortunately, this isn't as useful as it appears since many of the .NET class libraries are missing from the standard.  When Java gets new APIs, they become a standard that other vendors can implement (there are even reference implementations).  This has not and most likely will not happen with .NET.
  • The System.CodeDom namespace is cool.
  • Supports ValueTypes (structs) as first class citizens. "Int" is considered an object.
  • Access to native code is easy.  A lot of thought has been given to the runtime marshalling infrastructure.
  • When overriding virtual methods you have to explicitly state that you're overriding with the overrides keyword.

The CLI submissions are only a small subset of the .NET framework. This is for a good reason, most of .NET relies on Windows services (System.DirectoryServices, System.Windows.Forms, System.EnterpriseServices, ...).

C# and the CLI does NOT make up a platform like Java. It's more like C. Both C# and C provide a basic set of APIs. Anything more 'advanced' is provided through extension libraries that may or may not be cross platform (just like C). You could write a sound library for C# that uses DirectSound and it would only work on Windows. On the other hand, you could write a sound library for C# that uses OpenAL. It would work on all platforms where OpenAL is supported.

Many features found in Java (such as GUIs, Telephony, Speech, Sound, 3D) aren't supported by .NET and certainly won't be standardised. Sound support will be added by Microsoft in the future but it will use DirectSound (obviously NOT cross platform).

The cross platform hopes for C# pretty lie in OSS hands. It is up to the OSS community to write 'standard' cross platform libraries for C# (just like we have for C). C# interfaces nicely with C so it is likely that many cross platform libraries for C# will use the corresponding C libraries.  This will be made easy by the fact that C#, unlike Java, has outstanding support for communicating with native code.
The CLI is much more like C+LIBC than the "Java Platform".

Java is a meta-operating system. It supports a huge set of APIs that are consistently implemented on all platforms.
C#/CLI does not always provide a consistent API on all platforms but it allows and encourages you to rely and exploit on the native APIs available on the underlying operating system.

Which is better? It really depends on what you want to do. Java is currently the only choice for cross platform development. C# however, appears to be a good replacement for C -- especially on the client side. C# complements the underlying operating system whereas Java tends to hide it. This is why you will see a lot of C#/GTK# applications for Gnome in the future but not many Java/GTK applications.

No comments:

Post a Comment