Due to the fact that I already had switched from Windows to Linux at home at that time, I thought by myself, that this would be the opportunity to learn a completely new langauge which is platform agnostic and enables me to write applications that run on both environments. Using a computer I can't program (the Linux box at home) was a horrible situation for me.
About a year later, after several evaluation phases and another attempt with C# to give it a second chance, I decided to go for Java with two core advantages (apart from the language specific reasons):
- Develop once and run the binary anywhere - on Windows, Linux or even Mac.
Yes, I know the critics, that Java or other attempts following the "write once, run anywhere" paradigm do not deliver this promise (see comments on Wikipedia to cross-plattform development for example). Now, years later and after a few applications developed (commandline, server, Swing rich clients) my experience is very good. Of course if your development machine runs Windows and you use Windows API exits or use com4j, J-Interop or JACOB to interact with a Windows-only COM component then you will have problems running it on Linux or Mac. For example: I have developed a Swing application that worked flawlessly on Mac even although I did not have any possibility to test it (I do not have a Mac). I was used to get problems with windows only applications just trying them on a new version of Windows! Of course I also had some compatibility issues e.g. when stripping invalid characters from filenames (different characters are allowed and not allowed on the two systems) or checking if a file is still accessed (there is no windows-like file locking on Linux) - but these are differences in architecture of the operating systems and that can be handled. You can develop for many platforms also using C++ for example but then you need at least one instance of each operating system at your fingertips to do the compiling work.
- Reduce dependencies
You already run a risk choosing a programming language. You have a learning curve and invest into know-how, library development and maybe also buy some external components - not to speak about the related tools you learn to master (IDE, packaging, deployment, ...). But this is mainly your own risk. The even bigger risk is for the customer using your application when it is not plattform agnostic. I have seen companies trying to migrate a few servers to Linux and were stuck because of software running on Windows only. You don't know which operating system survive for the longer time. With a platform agnostic solution you just don't care. It's a matter of flexibility.
Having now the choice between several IDEs I first used Eclipse (free) and moved to NetBeans later on (also free). The book, which was most helpful for me in learning Java (Javainsel) was and is very good (sorry folks, it's german).
The biggest advantage of Java - being platform independent - also is the biggest obstacle in a (still) Windows centric (business) world: To ensure plattform independency (as I explained above) means, that you should only use and do stuff that is available everywhere - or you need to implement to different solutions. The resulting problem is: How to deal with the Windows specific stuff?
My solution to this problem is in the first place to not use OS specific exists or use calls to Windows-only stuff. For applications that need to integrate with Windows stuff I try to keep the OS dependent part small (e.g. a VBScript) and let it communicate with the Java program via commandline, over the net or by saving files to watched folders. For example: To get the active window title under Windows the Windows API is a possible way to go while on Linux there is a commandline tool called wmctrl which can do the same. So under Windows you would write a small Windows program that uses Windows API to to get the title of the current window. Probably the easiest way is to write an AutoIt script which has a prepared function for this and let it return the Window information in the same way as the wmctrl program does on stdout. Your program then - depending on the OS it is running (you can find that out during runtime) - calls either the one or the other commandline tool grabbing stdout of the called program. So it is recommended, that you try to reduce the OS dependent parts to a minimum and split your application into components - and the smaller OS specific part finally needs to be developed twice or three times.
It was and is one of the core arguments of those developers on Microsoft (.net and C#) that they are bound to Windows anyway because they deal with so many other Windows-components. Yes, this is partly true and I do still a lot of Windows-specific VB scripting. But I always think in components and so there are several opportunities to write parts in a platform agnostic way. Even if it is not yet totally platform independent - later there is less work when an OS migration is needed. If you look at the trends of the last years, you can see one big related trend: decoupling or "loose coupling" of components (from COM and DCOM to SOAP and REST). Lately I read more and more about "Micro services" which - frankly spoken - is just a form of component oriented design. Anyway, that nowadays makes it possible to have processes on different operating systems written in totally different programming languages talking to each other.
In the meantime I also improved my C# knowledge a little and developed a few smaller things in C# where it did not really made sense to do it in Java. There are a few people dealing with both languages. Interestingly those people criticizing Java most are usually those who don't know Java and have never ever looked into something else but the Windows world.
Although Microsoft had the chance to create a "better" Java by learning from it, they did many things worse in my opinion. Many say that the .net libraries are better organized than the Java ones. I do not know the .net libraries very well yet, but I tend to agree. On the other hand there are a many characteristics where I prefer the Java way, for example:
- Properties (C#) vs Getter and Setter methods (Java)
- Delegates (C#) vs Passing interface implementations (Java)
- sealed methods+readonly variables (C#) vs final - one word that says it all in both cases (Java)
- Missing checked exceptions in C# - a Microsoft guy once told me that checked exceptions produce just bloated code and therefore something like this does not exist in .net. Well folks, it is about error handling - something, Microsoft may not care a lot about ;-).
- Ähem, want to talk about GUI development? - Windows forms or WPF? - Both seem to be unfinished I did not figure out yet, which of those will remain unsupported sooner. At least silverlight is dead... - I went for Windows forms so far and even for a quite simple GUI I was stuck with the shitty TreeView and a double-click-issue - bug report from 2009 and not fixed yet...
I will continue to do a increase my C# knowhow, but I'll be always more confident when I can open up NetBeans again and working on a component in Java.
See also: The programming language, Choosing a programming language, Popular Java myths.
