Advertisements
Posted by: jsonmez | February 8, 2010

C# vs Java Part 2: The Platforms (Desktop and Mobile)

The Desktop (Thick Client Applications)

The desktop platform, or thick client, is not as important of a platform as it was several years ago, and it seems to be getting less and less important everyday.  Although, like a pendulum, development seems to swing back and for between thin and think client experiences.  It seems as though the current trend is thick client functionality in a thin client package.  (The browser as the OS).  For this post I will assume the development of a true thick client application, which is one that runs natively on the client computer and is installed or executed from the client computer.  (Although, as I am making this statement I am realizing even that line is becoming blurred with Adobe Air and Silverlight.)

Java

There isn’t much choice here.  Really, it comes to two options.  Swing or SWT.  I’ll confess my ignorance here.  The only thing I really know about Swing is that a long time ago I wrote an application that bounced an image around the screen using a second thread.  I tried to do a bit of research here, but I am not coming up with a large amount of information.  Probably because not many people are actually doing thick client development in Java anymore.  I asked one of the best Java developers I know, (Sreenivasa Majji), and he was able to give me some information.

Apparently, Swing has gotten much faster and easier to use since last time I used it.  From my understanding, Swing is pretty comparable to the previous generation of .NET thick client frameworks, Windows Forms.  SWT also seems to have comparable functionality, including data binding.  The real advantage that Java has here though, is the multi-platform capabilities.  A Java desktop application can be run on any operating system that supports Java.  (Which is pretty much any operating system.)  Deployment has always been an issue in thick client applications, and Java Web Start tends to solve that problem by allowing a client to visit a web page to launch the application.

I have heard complaints that not much progress is being made on Swing or SWT.  Which seems like it is true.  I know finding information about the technologies is not very easy.

C#

The current generation of C# thick client applications use WPF.  WPF is basically a wrapper around the DirectX libraries which uses XAML, (an XML based scaled vector graphics UI convention), to create the user interface.  WPF development is different from Windows Forms development in many ways.  WPF development separates the UI from the logic behind the UI very clearly.  XAML is used to define the layout and elements that exist.  The UI can almost be completely independently developed by a designer.  Everything in the UI is completely customizable, any control can be drawn from a vector representation replacing the default version of that control.  Animations and 3D graphics are easily achieved since WPF is built upon DirectX instead of the Win32 libraries.  The UI is also scalable since everything is represented in vector graphics.

Desktop development with C# using WPF is very nice.  I haven’t done a large amount of WPF development myself, but what I have done has been pretty easy and straightforward.  The power to use any SVG image or animation can make for some pretty nice UIs.  It can also make from some pretty inconsistent UIs though.  One major advantage that I see for WPF is that it uses XAML, which is the same technology that Silverlight uses.  I know that Silverlight and WPF are not 100% compatible at this point, but they do share many commonalities.  I have heard of a few frameworks that try to abstract their difference, but I don’t know of one that does that really well yet.  I am sure one will be developed, or Microsoft will provide a solution in the near future to make it possible to build an application that can easily be run as a WPF or Silverlight application.

Conclusion

In this case, I think it depends where your install base is.  If you are targeting a Windows user base, I think it would be pretty difficult to come up with a reason to use Java over C# for desktop development.  If you are targeting a multi-os install base, C# could be used to do Windows Forms application development using Mono, but Mono doesn’t support WPF.  Java is the most logical choice for doing a multi-platform install if you have to use a thick client.  I especially would not want to try and troubleshoot a bug that is different in Mono vs the .NET CLR.  I tend to see most traditional desktop applications being replaced with Rich Internet Application (RIA) technologies like Adobe Air, Silverlight and JavaFX.  One other side note here; Java and C# are able to call into unmanaged libraries (or native code), using P/invoke for C# and JNI for Java.  If you need to do that, C# P/invoke is by far easier than JNI, especially with the dynamic keyword being added to C# 4.0.

Mobile

Welcome to the next battleground.  This platform is under heavy turmoil right now.  Microsoft is being killed here by Apple and Google, both producing by far better user experiences.  Unlike the other platforms, the choice of language and technology here is more driven by adoption than by convenience.  What I mean by that is that there is almost no point deciding what technology to use based on language or features, it is more based on what kind of device you want to target, and who is winning the mobile device war.  Now, this is not entirely true, since there are ways to develop in C# on the iPhone ,as well as, Android platforms.

Java

When talking about Java mobile development there are two branches, Java ME, and Android development.  You can disagree with me if you want, but as far as I am concerned Java ME on mobile devices is pretty much dead or dying.  The idea, however, is great.  Multi-platform development on the widest landscape, mobile phones.  But, the user experience was pretty much horrible.  I have had several mobile phones running different OS versions and each one that had Java on it had some applications that weren’t really that great and didn’t integrate into the phone well.  Apple blocked Java out of the iPhone anyway, which is a huge market sector.

So, let’s talk about Android.  Android is awesome.  I love the idea, the technology is great, it is constantly improving and the architecture is wonderful.  Good job Google, you have made an easy to develop for platform that Java developers will be able to quickly adapt to and use to write rich mobile applications.  Android development is basically writing Java code, which gets converted to a specialized JVM that sits on top of a Linux kernel and some graphics APIs.  Applications use a provider model, which allows mashups of different applications as one application’s requests can be fulfilled by part of another application.  The development environment takes minutes to set up if you use Eclipse.  The UI is nicely separated from the code through the use of layouts and resources.  My only real complaint at this point is that you currently have to look up resources by an ID then cast the resource to the appropriate type.  The build is already using code generation to create a R.java file which holds the references to all the resources.  I cannot understand why Google didn’t make that code generation generate strongly typed methods for each resource.  Perhaps I am a fanboy of Android, but I have to say, I like it and I think it is the future King in the mobile market.

C#

Do you know how easy it is to create a Windows Mobile application in C#?  It is so easy that if I gave you Visual Studio and 5 minutes, you could probably figure out how to make “Hello World” appear on the Windows Mobile emulator.  Really, it is that easy.  It’s a shame that the current version of Windows Mobile is so lacking.  Now, don’t get me wrong.  Windows Mobile is powerful.  It is amazing what you can do with Windows Mobile so easily, since you have the power of almost the entire .NET framework at your fingertips.  It is a well designed OS, it run applications really well, it transfers the Windows look and feel we are all so familiar with to a mobile device very well.  But, that is exactly what the problem is.  It is not really an OS designed for a mobile phone.  At least not the way people really want to use their mobile phone.

So, let’s talk about the development environment for Windows Mobile using C#.  It is almost exactly like developing Windows Forms applications.  It’s incredibly easy, and for the most part, you don’t even realize you are developing for a mobile phone.  The emulator is built right into Visual Studio, you just hit run and it launches the emulator and your application.  The .NET compact framework has fewer features than the full .NET framework, but most of it is there.  One difficulty though is trying to get into the core services of the phone.  It is not very easy.  For example, trying to replace the dialer application is not really possible.

Silverlight mobile may save the day for C# development on mobile devices, if Microsoft can manage to bring it to iPhone and Android, but for now it’s unknown.  Also, the next generation of Windows Mobile devices using Windows Mobile 7 may change the game for Microsoft, but with it’s Q4 2010 release date, I fear that it will be dead on arrival.

Conclusion

Mobile development is kind of like the wild west right now.  It’s a huge risk to settle into a technology platform.  I place my bets on Java and Android, because it seems to me like the best combination of a good operating system and good development environment.  I didn’t really mention this, but iPhone development using objective C is ridiculously complicated and makes me want to smash my head into the wall.  Having done both Windows Mobile and Android development, I would say Windows Mobile development is slightly easier, but they are pretty comparable.  The reason I would choose Java and Android despite this is because Android is a better platform, a growing market, and has a delivery mechanism to easily sell your applications.

Final words

Comparing C# and Java development platforms is very difficult due to the overwhelming amount of information out there about each platform and language, but I have tried to take a fair and honest approach.  It is pretty clear that each language and corresponding technology have advantages and disadvantages at for each platform.  I can’t pick a clear winner from the platform perspective, like I could with the languages.  In the next part I will talk about the non-platform specific frameworks that Java and C# have to work with.

C# vs Java Part 2: The Platforms (Web)

C# vs Java Part 1: The Languages (Continued)

C# vs Java Part 1: The Languages

Advertisements

Responses

  1. I am not a WinForms expert but I do not agree with you regarding Swing vs. WinForms comparison. Swing implements MVC at UIControl level (not at application level) and is much more powerful then WinForms. There is no much talk about Swing lately because everything was already said 10 years ago. Take a look what this guy is doing with Swing, would it be possible with WinForms http://www.jroller.com/santhosh/date/20050610 ?

    • I didn’t really address winforms. But I have created custom control in winforms that would have been able to implement similar functionality, although not as easy as that Swing example. WPF is not winforms though.

  2. Over the last few weeks I’ve undertaken a task of converting a Java project with 36k lines to C#. Other than the UI stuff, it is dead simple to convert from Java to C#. Even the reflection hasn’t been that hard. As I optimize the direct translations, it’s made me realize a lot of huge advantages of C#.

    The first is “foreach” and “indexers”. The code is so much cleaner when using these. Years ago when I did PHP work, PHP OOP hadn’t yet come of age and everything was arrays, indexes, and foreach loops. I got so comfortable when them that I couldn’t conceive of a language not having them.

    Another big C# advantage is delegates. The Java code I’m working with has dozens of observer pattern implementations that Java uses instead of delegates and events. I can refactor away many Java classes and file using 1-3 line long delegate and event C# code.

    The final huge one is generics. It may just be the code base I’m working with, but most Java I come across relies on native primitives to do all the work and un/boxing “object”s when another class else is used. This is horrible! Type-safety aside, it’s just not as descriptive and intuitive as it could be. I only need to know that a variable is of type List to know exactly what it holds. I don’t have to remember or reference how it was used. All that casting feels so cumbersome and ugly to me now.

    After reading all of your posts – and they’ve been wonderful – the biggest reason I stick with C# instead of Java though has gone unmentioned: the IDE. I think highly of C# and love using it. I enjoy the features, the syntactic sugar, and the tremendous community. In the end though, the IDE alone would keep me using it even if it sucked as a language.

    To me, using Eclipse to code with Java feels like a sturdy SUV going through the mountains. It’s rough, it’s tough, it can handle anything capably, but it’s still a really bumpy ride and my knuckles are white the whole time.

    C# + Visual Studio feels like a yuppie SUV going down the highway. I’m every bit as safe, the road is smooth and I’m gliding along. I’ll still never confuse it for a sportscar or motorcycle but I’d much rather be sailing down the highway than through the mountains.

  3. You don’t have to choose now. Use both of them http://jni4net.sf.net/

    Enjoy!


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

Categories

%d bloggers like this: