Visual Basic Classic was my primary programming language for many years. A pretty amount of years ago when Microsoft announced the end-of-life of Visual Basic Classic (one of the last statements regarding VB6 see
http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx) I took a first look at .net and C# as it seemed to be the most logical next step. I was deeply disappointed by the first versions of
.net and
C# (it was v1.1 if I remember correctly - it was so full of bugs and terrible slow). The next shock for me was the absence of any migration path for the existing VB classic projects. So switching to .net would have been a total restart. I really wondered about that step of Microsoft because pretty every software vendor knows that a hard cut in backward compatibility of software comes with the danger that customers start taking a broader look around to competitors.
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.
I can see further advantages, like choice of
IDE or missing licensing issues (Visual Studio license usually provided by the employer and when you leave you have to find a new sponsor).
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...
In general Java is easier and simpler (less language constructs - not the libraries) in my opinion, but sometimes there might be more code for the same thing, but who cares? - It is important at the end, that you don't refuse touching again your code from a year ago (not to speak about the code of others ;-) ).
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.
