The "Java is dying" tale

And there was it again... - somebody (in a Java group - strange enough) told that Java is dying. Uff! - I hear this for years now - and it gets annoying to hear or read this again and again (of course of the people who don't like - or simply don't know Java).

Nevertheless, Java ranks within top 3 programming languages on whatever index you look!
But probably you should also consider, where you live, because there are statistics over countries which shows that most important language depends on country - e.g. here:
https://blog.hackerrank.com/which-country-would-win-in.../ (Java is there first for Poland, Python for Hong Kong for example).

Oh - this article (even if older) already talks about the Java is dying tale: https://jaxenter.com/java-slippery-slope-downward-trend...

What makes Java still a very important language and still very attracting for newbies, is the wide field of usage - from desktop over web and not finished at mobile development. Especially when searching for a first language to learn which can be used to do it all.

Another fact is, that there are many open jobs (at least here in Austria) for Java Developers at the moment - so knowing Java currently helps if you need a new job...

Related posts: The programming language discussion, Java vs .net/C#, Choosing a programming language, The programming language, Popular Java myths.

The programming language discussion

And there it is again - the programming language discussion - Not a single developer forum or group that does not have it at least once every month.

Don't get my wrong, there are many good programming languages out there many are worth to be learned. Although I learned many through the years, I know very well that one cannot be expert in a lot of languages. You can only be an expert in that what you use often. 

Sometimes I need to look into old VB Classic code and after a while I am back into it - but not coding in the same speed as back then when I used it on a daily basis just because of the fact, that I don't remember well all the libraries and their functions I wrote back then.

When the programming language discussion comes up, the arguments are about what is the "best" programming language or what is the most "widely used" language. But I consider this being secondary priorities.

Learning a programming language is an investment!

You need to consider, what are your needs and learn what will bring the best return on investment for you!

I found the following strategy being very useful:
Have one primary programming language - or at maximum two - that you know very well and basically can be used to solve all your programming needs (batch tool, server daemon, desktop application, web application and mobile application in best case). Then have 2 or 3 programming languages that you can use for particular needs in special cases where your primary language is not so good at.

Choose wisely the programming languages you learn!

Related posts: Choosing a programming language, The programming language, The IDE and the libraries, The "Java is dying" tale.


Java vs .net/C#

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):
  1. 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.
  2. 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.


IT ball and chain

After a very intensive year (which means a lot of work and a minor amount of sleep) at least I have been on vacation a few weeks this summer (in chunks). For two weeks I totally abstained to use a computer. I only used the smart phone from time to time for a phone call or checking mail / searching something in the internet (in total not more than approximately 2 hours) or reading the news. That has (again) increased my awareness that a computer does not always increase the quality of your life. Coming home I experienced some of the biggest annoyances of IT:
  • Maintenance work
    • System and application updates - they take a lot of time and attention (e.g. permission check on Android during application updates).
    • Declutter and free space on drives (to download pictures from the camera to the computer in my case) or on Dropbox to get the pictures uploaded that my wife took with the smart phone.
    • Delete spam or less interesting emails.
    • Make secondary manual backups.
    • Fix hardware defects (change old-age harddisks etc).
  • Trouble-Shooting
    Be it end-user support or administrative support. Errors may happen during updates, some passwords might be expired while you have been away for too long without logging in, some features (after an update) suddenly not working any more as you expected or - after not using for a while - you might not remember well how to accomplish a task seldom needed.
  • React to changes in IT world
    In my case during the updates on my mobile devices I have seen that many applications do want new permissions regarding device ids and call information. So the first action was abort a lot of updates and search the internet for possible reasons and for options to restrict this alarming trend against privacy. Lately there were plenty of news causing administrators to take action, like the SSL heartbleed bug or other alarming information, e.g. leaked by whistle blowers (like Edward Snowden). Not to speak of more long-term changes like technology shifts (those do not happen just during a single vacation, but while reviewing the past year you might notice a trend that needs to be evaluated).
The longest-running tasks during my vacation were washing dishes (no dishwasher in the rented appartment), sweeping and disemboweling fish (take out guts) as well as brushing away the fish scales (adhesive bonded onto the wall), but none of them took longer than 45 minutes. Last weekend I tydied up the storage room in about an hour. In my IT work I can be very happy if something can be done under an hour.

And now take the annoyances mentioned above and multiply with the amount of devices you have... - I fear the time, when even my washing maschine needs to download updates and doing reboots before it can start washing - super annoying...

As a child, one of the main reasons why I got fascinated by the computers, was the fact, that it can help you making a lot of tasks faster and more efficient. Nowadays you have to pay attention that the total cost of ownership with maintenance work together with the velocity of change does not outweigh the benefit of the automation.

Related post: The truth about software.


Dropbox Icon missing in Ubuntu

On Ubuntu 12.04 as well as 14.04 with recent versions of compiz, dropbox or whatever other module the Dropbox icon may be missing in the upper right corner (system tray) after login.

This is in general just an annoyance because Dropbox is still running in background (you can check this by opening your Dropbox folder and you will see the checkmark icons and the dropbox context menu entry when right-clicking a file - which are only visible when Dropbox is running).

However, I found several forum and blog posts mentioning that
sudo apt-get install libappindicator1
solves the issue or
sudo apt-get install nautilus-dropbox
solves it. I already had libappindicator1 However in reality the latter is obsolete as the nautilus integration is no separate thing any more. So both did not solve the issue for me.

I solved it permanently only by writing a short shell script (which i put into /opt directory):
 sleep 60s  
 dropbox stop && dropbox start -i &  
(mark as executable) and then click on the Ubuntu button on the left upper corner, type "startup" and there add an entry to call that start that shell script /opt/dropboxrestart.sh.


Reinventing the wheel

There are three kind of developers when it comes to library use:
  1. Those who extensively use existing stuff to avoid reinventing the wheel,
  2. those who do code the stuff on their own and try to reduce as many of the  external dependencies as possible and
  3. those who do the easy stuff on their own and only for big topics (like PDF or MS Office file handling etc) they use existing libraries.
If you want to avoid reinventing the wheel completely then you will end up with a lot of library dependencies which often even do not fit well together (just think of the many different java logger frameworks available).

Neither the first nor the second extreme will bring the optimum result - at least not when you think long-term.

For example I was using ini4j to load inifiles (because I was under pressure) but later I noticed that the sections are internally stored in a way that you can not rely on getting them loaded back in the proper order. For the project where I was using it, order of the sections previously wasn't really relevant (that's why I didn't either recognize that ini4j was mixing them up occassionally), but then things changed and now order of some sections is relevant. So I had to change the underlying library. I took the chance to implement the inifile handling on my own. Why? Would I have been the developer of that library I could have changed the internal implementation who the sections are loaded in an instant. Without being really involved into the project I would have needed to read into the foreign source code (which unfortunately is always more difficult than reading your own code - if you did it well) and doing code changes that hopefully will not be rejected by the project owner (loosing it again with the next patch). I would have done this probably, if it wasn't urgent and if inifile handling wouldn't be such a core thing for me (I deal a lot with inifile style files).

And here it comes to a related topic:
You can get your code being written almost everywhere around the world, but the important questions are: If you need a fix or an enhancement,
  • do you have a chance for direct communication with the developers (or how many levels of communication are in between)?
  • how fast can you get what you need?
Of course, when using a big library that is widely used you may get a very good and stable code base, but bigger changes will not be easy to get quickly.

I have seen it plenty of times, that having the full source code available at hand is the only guarantee to get fixes or enhancements in time when you need them!

And there is another related topic: Progress
Sometimes it makes pretty good sense to reinvent the wheel - and indeed if you look at the wheel itself, it has been reinvented (or at least adapted) many times and looks very different depending on the core usage and environment. For IT or source code this means that for instance the same stuff must be programmed again and again when you change programming language or when newer and better technologies can only bring benefit when you partly rewrite the application.

I write this because often the thought of reinventing the wheel is labeled so negatively. Rewriting code parts or writing them yourself instead of using an external foreign library can make really good sense!

Related post: Bronze age of IT.


IT Dependencies

Lately at a customer I got introduced to an application written by an employee which should be replaced. There were some special features that have been implemented for the exact needs of the company. After a while I began to wonder why they want to replace it. I thought by myself: "What could be better than an application written exactly for their needs by a person who is actually in that company for a long time now?"

Finally at the end of the meeting after the others left, I asked the project manager at the company what the real reason is that they want to replace that program. The answer was: They want to get rid of dependency of that piece of individual software development and dependency of a particular person. They want to use a standard software.

While this sounds quite reasonable, I want to clear-up potential misunderstandings:
  1. Even betting on the biggest companies and their products does not save you from the risk of software being discontinued or services shutting down.
    For example here is a list of software products discontinued by Microsoft. And this does not seem to be a complete list because from the first look I already miss the Visual Basic Classic which is also dead (and I have A LOT of experience with that which will be dead know-how in a few years).
  2. Even the largest company-group sends you individuals that do the work and guess what: In most bigger IT projects (even when using standard-software) you usually end up with an individually customized piece of software and often with several project specific extensions. And who knows best your system? - The one who has done it! Change the person and the person needs time to analyse and get into it.
  3. As time goes by most companies, when they start to buy external know-how or services, they begin to loose control. To reduce dependency you would need the source code, the know-how and the access. One effect of extreme outsourcing often comes with loosing your privacy and security.
So by switching to a standard product it is not very likely that you are reducing dependency. Often you save internal IT manpower for other things but you trade it for dependency or for privacy. Paying a developer for permanently being ready for implementing your business needs may not be the cheapest solution but you get flexibility and often reduce communication flows.

For many very tiny companies it might be perfectly ok, accepting the dependency from external services when they don't have to bother about their server-backup etc then. And so privacy is also traded (e.g. free web service for providing your personal data).

It is a matter of your values, your priorities, your time and budget etc. if you better have a server in-house or use some online-service in the web.

So what can you do?
  • Be aware of your values
  • Be aware of your business focus
  • Be aware of your (human) resources
  • Remove resolvable dependencies
    which means: Prefer forward-looking software products and plattform-agnostic open-source software over more limited alternatives.
  • Distribute work and risk (e.g. have an external partner helping you but also have an internal administrator/developer who can do the work).
Related posts:  Priceless Developers, Surveillance, Privacy (NSA, PRISM, ...) and encryption, The truth about software.