Hesam Seyed Mousavi, September 30, 2018
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 forth 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 we 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.
Source: prproject
Java
There isn’t much choice here. Really, it comes to two options. Swing or SWT. I’ll confess my ignorance here. 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 to help me, 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. The power to use any SVG image or animation can make for some pretty nice UIs. It can also make for 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 runs 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.
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.
C#
Pros:
- Easier to learn than c++
- Easier to read code than c++
- More rapid and potentially less error-prone development than c++ or java (you have unsigned types, you have ref/out, you can make your own value types, you have other useful things that java omits which means you have less jumping through hoops, which means less unnecessary code complexity).
- All things are passed by reference except for value types, by default
- Garbage collector cleaning up objects once they’re no longer used, so you don’t have to manually track everything yourself
- Program is compiled to native binaries optimized for the platform when it is run (and yet it ran slightly slower than c++ code).
- Easy to make multiple threads
- Have a variety of means of suspending threads to wait for signals and such
- lock(someObject) { code }, which is kind of like java’s synchronized but can be used anywhere and requires an object.
- P/Invoke is much easier to use than JNI – but we probably wouldn’t use it since we want to be cross-platform
- Has an excellent free IDE (visual c# express) – but on windows only (see cons).
- You can make value types, which are by default pass by value instead of pass by reference, by making a struct instead of a class.
- You have ‘ref’ and ‘out’ keywords which allow you to pass a reference to a parameter to a function, with out meaning that the parameter must be assigned by the function before it returns. Essentially, ref/out allows the function to modify the variable being passed as the parameter, like passing a reference in c++.
- Fairly cross-platform with mono, and/but mono is still improving
- Has unsigned integers (so does c++, java doesn’t)
- If the program crashes, it pops up a dialog telling the user where in the code and why (on windows) or writes a stack trace to the console (with mono if run with –debug).
- Programs are compiled to .exe files, and don’t need to be recompiled for other OSes – mono can directly run .NET exes.
Cons:
- Uses more memory than c++
- Garbage collector using CPU cycles and memory – (but barely any, at least CPU time)
- Some things don’t work in mono – calling functions in some windows dlls which won’t exist on linux, mono implementation of windows forms need workarounds in code (but we probably won’t use them)
- Mono isn’t perfect yet
- Have to use .net 2.0 for generics (among other things), 1.1. doesn’t have them. Can’t use anything newer than 2.0 because 3.0 and up drop support for for windows 98, ME, and maybe 2000.
- Can’t declare functions synchronized
- No good IDE on non-windows. Eclipse has a c# plugin but it might not support most of Eclipse’s features.
- No pointers, but they’re replaced by ref and out parameters, so they’re not needed much
- Calling methods via delegates are significantly slower than normal method calling (or function pointers in c++, presumably)
- Requires the (correct version of the) .NET framework to be installed to run the program, which is a several hour download on dialup.
Java
Pros:
- Easier to learn than c++
- Easier to read code than c++
- More rapid and potentially less error-prone development (due to less memory management) than c++.
- Most cross-platform since it was designed for it and Sun makes JREs and JDKs for most platforms
- All things are passed by reference except for value types, by default
- Garbage collector cleaning up objects once they’re no longer used, so you don’t have to manually track everything yourself
- Apparently java 6 runs (some?) stuff slightly faster than c++ (test code ported from c++ ran faster despite having to do seemingly wasteful things!)
- Program is compiled and optimized for the platform it’s on, if necessary?
- Easy to make multiple threads, and you can declare functions synchronized so only one thread can be in them at a time (IIRC)
- You can use wait() and notifyAll() and notify() to suspend threads to wait for signals and wake them up again.
- Various free IDEs available on all platforms, such as Eclipse
- If the program crashes, it should either tell the user where in the code and why, showing a stack trace including line numbers (if debug symbols are enabled or something like that), or it can be dumped to an error log file.
- Programs can be packaged into jar files with various data files in different jar files and accessed by users using Java WebStart, which will auto-update the program and any other needed jar files to the latest version, only downloading what jar files have changed.
- Easier/more cross-platform networking than c++.
- Files are read and written as big-endian on all platforms (which is network byte order) ensuring that communications between java programs and file loading never require byte-order swapping (unless talking to a non-java program or using a file written by one).
Cons:
- Uses more memory than c++ or c#
- JNI is terrifying, but if we’re being cross-platform we probably won’t use it, (except that the 3d engine will?)
- Garbage collector using CPU cycles and memory – (but barely any, at least CPU time)
- No unsigned integers
- No pointers, no ref or out parameters (which replace pointers in c#). To return multiple things from a java function you tend to have to return an object[] holding each thing, or make a class which holds each thing and return an object of that class.
- Some things were renamed – const is final in java, for example
- Java does not allow indexers or operators on objects, e.g. if you use resizable lists etc, you have to do list.get(index) instead of list[index], and you can’t do someVector + someOtherVector.
- Java does not let you decide whether a type should be a value or a reference type (determining if it should be pass by value or pass by reference), unlike c#.
- Jar files used by java webstart have to be signed with a certificate. Code signing certificates cost hundreds of dollars per year, or you can make a self-signed one and use that, which will make Java Webstart pop up a “This certificante can’t be verified” dialog when the user tries to run the program. (Alternately, don’t use Java Webstart and just distribute jar files directly – which requires users to check for updates themselves.)
- Requires a JRE to be installed to run the program, which is a several hour download on dialup.
- Have to use java 5 for generics, 1.4 doesn’t have them. Java 6 is newest and a couple years old, but – Apple releases their own java versions for Mac users, and still hasn’t released a “stable” java 6 version for its users.
Software Architect Blogs 