What factors to consider when choosing runtime/language for Windows desktop applications?

Question

My users all have Windows. Some of them use Linux or a Mac, but if they do they're generally capable of using something like Mono, Wine, Parallels or dual-boot.

My development team (including myself) has extensive experience both in writing Swing applications in Java as well as Windows Forms in C#. "Extensive" means we've developed and shipped over three applications on both runtimes. The applications are technical analysis applications, so mild on database interaction, but heavy on custom UI and data set sizes.

We're coming to the point where we really want to make a decision as to which platform to focus on from now on, since it's becoming a burden to support both (if you're working in Swing for half a year it's too much hassle to get used to Windows Forms again and the other way around) and we want everyone in our team to be capable of working on all of our applications.

• Windows Forms generally takes less work to make recognizable Windows applications. No amount of skinning and custom controls in Java has solved that over the years. At the same time, we've never had a customer that couldn't use the Swing applications.
• Java used to have a much richer ecosystem in terms of libraries and automated build tools, but that's changing rapidly (Java is not going down, it's more that .NET is catching up).
• For the rare case that multiplatform is preferred, Java beats .NET hands down. Mono is wonderful, but it's still more work than Java.

If we choose .NET we can start to focus on WPF, but also start using F#. If we choose Java, we can start to focus on RCP, but also start using Scala.

Has anyone had to make a similar decision? If so, what was it and what influenced you the most? Any top concerns I'm missing?

(Please note: there are some similar questions on Programmers.SE already, but they're either unconstructive or from a different angle.)

Answer 1

We went for Java (Swing) plus some native parts via JNI. While the commercial demand for multiplatformness may be marginal today, the situation may be different in 5 years, and the app's (a scientific measurement app) life cycle is going to be more like 10+ years (its C++ predecessor, still used today, has source files dated 1991). As you wrote, Java beats .NET hands down in non-Windows environments, and if we ever need to switch away from Windows, it's just a matter of re-compiling some native parts, maybe fine-tuning the GUI looks, and checking that everything works.

If you're sure you'll be Windows only, and your app is going to live just few years, then .NET may be preferred - it looks and behaves more like a native app because it is. But as a long term investment I trust Java more. Swing may look a little less than perfect, the start-up time may be longer, everything is a bit sub-optimal because of the multiplatform abstraction layer, but at least it "just works".

Answer 2

A thing you may want to consider is the IKVM project which allow you to use Java code in a .NET world. You can then get the benefits of a Java backend, while - to my understanding - you can have a thin frontlayer in either Swing or WinForms.

http://www.ikvm.net/

I have heard that others have used this to use an open source connection library written in Java from .NET instead of having to use the cumbersome .NET version.

Answer 3

There's a resource on MSDN that might be useful to you: http://msdn.microsoft.com/en-us/gg715299.aspx.

If you go to the bottom of the page you'll find a bunch of whitepapers that compare Java and .NET conceptually. Of course since it's on MSDN it's biased towards .NET, but the resources are still quite useful.

Answer 4

I've done some thinking around this as well, and I've found the answer depends on the type of project and what you can foresee about it.

Sometimes, creating the One Codebase to service all platforms is a good thing - you get some level of UI consistency with less overall code. I think the advantages and disadvantages are obvious, so I'll skip that.

There are times when having 2 natively-written code bases is better. If, for example, writing your app in WPF is elegant for .NET, and writing it in, say, Cocoa is elegant for Mac OS, the resulting code might actually be smaller than using, say, Java or Mono (which does not have WPF). In that case, you might get better results with less code.

A final consideration is perhaps doing your app as an HTML5 application, or even a Chrome extension, but that might be too left field.

Answer 5

Have you considered Silverlight? It can be a good choice for build also Windows Desktop application (from SL4+) and work fine on Mac.

Answer 6

As a full time Java developer I can tell you that while the cross-platform compatibility is amazing, each and every native integration is hell.

I always had many issues, and sometimes failed, on this ground. You may not need it, but sometimes I stumble upon it and it usually hurts.

• Integration with COM is pain, and COM+ is sometimes impossible (wasted weeks trying to get it to work with Windows Tablet API).
• Hardware interaction can hurt. Sometimes the API is only available on one platform (e.g. camera/scanner integration).
• Interaction with local applications can hurt, too. Did I mention that COM pain? Well, another way (that we actually used) was to generate and execute VBS scripts that launch a Windows application such as MapPoint or some proprietary mapping app and feed it with data.
• Installation and desktop integration (shortcuts, uninstaller, start menu) can hurt, too. Web Start is very unreliable. Alternatives either cost you dearly, or are missing some features (like update distribution).

Don't get me wrong. I am a Java developer and don't mean to flame it. I'm only saying that if you suspect you will need any of the above, it can hurt and you might be better off with .net. At least it's an argument that you should take into consideration.