Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

2018-02-05

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.

2015-07-23

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.

2014-01-07

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.

2013-10-15

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.

2013-09-25

Priceless Developers

When I get contacted by headhunters they are usually searching either for a developer or for a consultant and there is an interesting observation which I do see confirmed when I read forums or talk to friends:

Companies are willing to pay much more for a consultant than for a developer.

I am both - developer and consultant - and I can tell you: The best consultant cannot solve the issues that have been introduced by bad programming and software design mistakes. In a software company the whole business depends on the quality of the software released to the customers.

Only in very rare cases in my consultant role I have access to the source code of the base products in use at the customer. My daily job includes customizing bricks of software and tying them together. Of course this often means writing code on my own to make everything work together. So I am dealing a lot with APIs of software products.

During implementation of projects the vast majority of time goes into dealing with bugs, unfinished features and bad software design (or a software design that simply does not fit the needs)! And is pretty irrelevant which software product I am thinking of, it's the same everywhere. It would be better if I could focus on the customer needs and on building solutions instead.

There are people who have the opinion that most problems are just organisational problems or can be solved on the organizational level. I do not really agree with this. Of course, in most companies there is room for improving the organisation, but a software flaw should not be the reason for implementing workarounds on the organisational level.

Software vendors and their customers depend on stable, secure - good quality software. Those, who are building the software, often are poorly paid. Most of my ex-class-mates stopped the programming work completely in the meantime. In the same time I do not know any software vendor having enough good quality programmers. Instead bug lists are only getting longer over time. Really strange.

Related post: IT Dependencies.

2013-07-23

What the Tech Industry Has Learned from Linus Torvalds

Lately I often suppressed my gut feeling in some technical issues.

Finally I stumbled over a video that completely supports my gut feelings:

Jim Zemlin, boss of Linus Torvalds is talking about the lessons learned working with Linux:

Lesson 1: Don't dream big
Lesson 2: Give It away
Lesson 3: Don't have a plan
Lesson 4: You don't always have to be nice

2013-01-12

The truth about software

To summarize the software-troubles:
  • Too many bugs
  • Too difficult to use
  • Too much administration and maintenance work
As you might already know, as it seems obvious for you - or maybe, if you are listening to your inner voice, you only hear it from somewhere burried deep down in your mind: software is full of bugs. There is no bugfree software.

Since I started programming, I could see the IT world complexity growing and growing. In the beginning there was one processor and one process running at a time - no other software to integrate with. Everything was easier. When I think back to times of Commodore C-64 or when I was using the MS DOS Borland Turbo Pascal or C compilers - they were all extremely robust and when there was something not working as desired, I could be to 99 % sure that it's my fault. So at least the core system and the development platform were rock-solid and stable. That did not always apply to my programs... ;-)

Nowadays, operating systems and their core services as well as development environments - and in addition to that a bunch of third-party libraries all have their issues. So the software developer doesn't even start on a rock-solid base as it happened to be back in the early eightees (at least according to my experience - YMMV). In addition to that: If you want to produce cars, toys or whatever other physical stuff, in most cases you need a factory and a lot of money before you can start. For producing software, all you need is a computer and download some tutorial from the net and even a fool can get started - and unfortunately a lot of fools do...

But the low entrance barrier is only one reason for the lot of issues around. In my opinion the complexity is the worst thing here. Even with the honest strong desire to get everything right, you can't - apart from the fact that IT world has grown far too big to be completely covered by a single person.

But the growing IT world did not bring only troubles - we do have far more possibilities since computers were invented. Software development is far easier than in the beginning of computers. We can build software with far more features in much shorter time now. The problem: The software can often do far more than the users can handle.

And last but not least: I remember times when the "installation" of a program was just copying it to the machine and run it. Today it requires dependency checks and sometimes complex installation procedures. Although still possible - only a very few programs that run fine when you just copy them. Nowadays many software products have a bunch of required preconditions and a lot of integration options that need configuration. Highly integrated software means more maintenance work regarding updates (of any of the involved components). Another reason for increased maintenance work are the customization options that most software comes with.

A normal user nowadays is working with a lot of different software products and often there are some software products that are used very seldom only. I have seen users dealing with software they need to touch only once a month. From one month to the other they need to re-find all needed menu items again because from one month to the other they always forgot.

The challenge these days is:
  • To reduce complexity (of the problem and feature set) as far as possible (while maintaining flexibility).
  • To make using the software easier - software must be intuitive to use (only a very few people do read documentation or help file text).
  • And to make configuration obvious and simple.
Related posts: IT fallout and buddhism, New user experience, Proof of concept, IT Dependencies.

2012-04-05

Choosing a programming language

Currently - after a very long period I am again into the programming language decision which I was not expecting.

Changing programming language is a big deal and you shouldn't do that every 2 years. When you search the web you will find recommendations to learn many languages and learn a new each 2 or 3 years. I find this totally silly. To get really productive with a programming language, takes at least a year and of course you would like to get the most out of it regarding ROI (return on investment).

When I did evaluate programming languages the last time, it was a 3-step way:
  1. Collecting all options with the result of a hand full remaining for further analysis.
  2. Keep an eye on activity and evolution of the results from step 1.
  3. Detailed analysis of the remaining options and choose.
The time from beginning of step 1 until end of step 3 took about 2 years. During step 1 I already decided on a few parameters, which in my case were:
  • I prefer static typed languages over dynamic ones for several reasons (e.g. less error prone, YMMV).
  • I don't want to code user interface - I have coded GUI since I was an 8 year old boy and I was about 14 when I got GUI designers (those times still using MS DOS) so hand-coding GUI is for me like returning to stone-age and so that is a no-go for me if a GUI designer is missing.
  • I don't like language hopping and because of the very dynamic requirements of my software projects I need a programming language that can be used for quite all realms - so all the domain-specific languages are excluded for my needs.
  • My applications are usually plugin/addon enabled which means that a customer must be able to develop those for special needs on his own - without additional costs. That means, my favor goes to languages that are free (and open source) including the IDE used for development.
  • The language should not be tight to a particular operating system.
My decision - taken back in 2008 after many years of classic Visual Basic development on Windows was: Java together with NetBeans IDE, using Swing GUI for desktop applications (NetBeans itself uses Swing - however, there is another option for building GUI in Java: SWT). A short comparison Swing vs SWT can be found here. Back in those days I have already blogged about my decision, you might want to read back to "The programming language" and "The IDE and the libraries" maybe. The Swing GUI is - by the way - far superior to the .net WinForms or WPF - both do not adapt well to very different text lengths in labels (just to give one example - in Swing this works without additional work in full automatic). Another core advantage of Java in general is: You take the binary and it runs everywhere! - C++ and many other languages at least require the same code to be compiled on each platform. What if I want to develop for the Mac and I don't own one? - I have given Java apps that I have written to a friend for testing on his Mac and it worked - without me ever testing it on the Mac. Of course if you call system programs dealing with the output you may see differences in the behaviour on different operating systems that you have to deal with. The most annoying thing in Java is that you need to ensure that the Java runtime is installed on all the client PCs where you want to use the app. Of course no difference to Microsoft's .net here - although there is less version quirks than for .net...

Now, about 4 years later there is nothing wrong with my decision. My decision is still that. With the rising of alternative operating systems the importance of Java has gained (on the server side Windows definitely already lost for enterprise applications at least) and many server-applications go Java to be platform agnostic. Apart from that the Java world is huge. Microsoft's .net is growing also, but still far from that (regarding size and quality of libraries and community).

The trigger for my latest search for a programming language is that I have a few very small programs (running on the client) to write (they are not "real" applications, just tiny programs for particular small needs). I found Java - and .net or Mono as well just too big for such tiny stuff. In my particular case they are Windows specific needs. A few of those needs I already solved by just writing VBScripts. That was ok for the GUI less needs. Now I have a few little needs for small GUIs. And that again brought me to a brief look around.

And indeed that is the single parameter ("should fit for very tiny requirements also") I did not include in my former decision back in 2008. And good it was I think because finding the programming language that fits for really everything 100% is not realistic. It is even not realistic to think that a programmer nowadays can survive just knowing one language - but: It is important to keep in mind that no one can achieve the same level of expertise in all used languages.

So this post can be seen as an addition to my main pro-Java decision - the programming languages that are helpful in addition to Java.

For Windows development you should know VBScript and on Linux shell scripting or Python or Perl for the small scripting stuff.

But what to choose, if a little GUI is needed?

If you search for a platform independent development platform, you could look at Free Pascal and Lazarus IDE as it creates native code (so just take the executable and run it instead of writing packages or setups that manage plenty of dependencies) and is fast. There is one problem with this approach: On Windows (in my case) using COM components (not to talk about .net) is not well supported and possible only with quirks (not tried myself, I just read about that). That is the reason why this is not an option for me in my current situation. If your application does not need to tightly integrate into the Windows ecosystem Free Pascal gives you multi-platform development (same code, just need to be compiled for/on each platform).

After all, still core technology is C(++) and Code::Blocks is an IDE available for all major platforms (for wxWidgets projects the wxSmith seems to be the most capable GUI builder, you need separately install wxWidgets - at least on Windows). Or anyway you can either use NetBeans using external designers to build the GUI for Linux development. I have developed quite a lot C++, but maaany years ago and today I simply had problems getting Code::Blocks to work seamlessly with wxwidgets (design worked, but compilation finished with configuration errors). What I found on the net related to my errors was from about 2008 partly not matching my environment. I gave up on this but for those succeeding I want to mention this option.

Last but not least I still also see the option to use SharpDevelop with .net for the single reason of time-to-get-started and seemless integration into the Windows ecosystem - and this combination by the way is the only mentioned one that is bound to windows only. If you think of Mono and MonoDevelop then be warned about the differences! Creating platform independent applications with C# is not as seamless as you might think! Using  MonoDevelop on Windows (MonoDevelop can compile against .net or Mono) brings more platform independence but you loose the Windows integration (COM/activex support at minimum level - I find the Java-COM-interop even better; registry access and stuff like that). The very important point here is the Windows integration - it's the one and core argument for this option!

I was about to write a paragraph on speed but didn't want to write that without a single test after more than 3 years of not checking that. Surprisingly a minimum GUI test lead to the following result: Cold start on a virtual Windows 2008r2 machine is 5 seconds for both - .net as well as java. A second start is 1-2 seconds - either for both. I then tried a Java test application with a little more GUI to find out that (warm) start is 4 seconds - not bad either. Surprisingly Java 1.6 update 30 and .net runtime 4.0 seem to bring a similar user experience at least from startup behaviour. Many still say, Java is slow - far missed!

But I may not forget that I need to access activeX/COM components for my small work which makes it more feasible doing it with .net because .net simply integrates better here - as already mentioned. Of course there are options when using java - for example - my favorite com4j (which I tried for several COM components in the past where it worked well). Although I never tried to embed activex controls into a swing component - and that does not seem trivial in Java - see here.

Needless to say that I would prefer Java for 100% of the work if it would be easier to deal with COM components and if it would integrate nicely with the Windows stuff. Java with NetBeans is basically the only combination that I really love to develop with. Everything else lacks in IDE features, is difficult to set up or the community is small and tiny amount of available components.

And of course there is my general tendency to avoid Microsoft technologies whereever I encounter them. The classic Visual Basic was one of the longest continued stuff of Microsoft, even although there were signifficant changes between VB 3.0 and VB 4.0 (with switch to 32 bit). When I look at the last years there were unusable first attempts of .net with first Windows forms and then WPF (see a discussion here), Microsoft pushed a lot of newer GUI styles over the years with Ribbon interfaces or now the Metro GUI where you need to use a new GUI language and software companies continously need to adapt or rewrite parts of the application). Would I have used Java since the late ninetees I would have experienced a completely different continuity. Microsoft managed it very well, to drive developers .net without those getting aware that they are again caught in a one-way-street with a dead end. Just because industry follows Microsoft - at least on the client side - in most areas, I need to accept that I can't stay completely outside the windows specific (VBScript and .net) stuff. I will take care to keep it at a minimum. This means, that for my tiny programs I will most probably go with .net just because of the lack of other options.

For those who like dynamic languages, I want to mention Python. One of it's core advantages in my opinion is that it runs on many platforms but comes along with Windows extensions on Windows. This means: When you need to do Windows stuff you can continue to use Python - of course using the Windows stuff (COM and Windows API for example) means that (at least that part) of your program is then bound to Windows-only use. For platform agnostic programming there are bindings for wxWidgets for Python. However, the IDE's I tried were all poor in features or stability - I tried Eric, SPE and Idle back in 2008 - a short look tells me, that there is still a lack of GUI designers (e.g. Glade for Windows seems near to discontinued) - so I cannot really recommend a particular IDE - you can have a look yourself - here is a list of Python IDE's. Unfortunately deployment for Python programs on Windows is not as easy as for .net or Java.

To round up this post: For building setups for your Windows applications I can recommend the Innosetup application as a good mix of flexibility and ease-of-use. For creating Linux packages see official documentation for creating .deb packages (Debian, Ubuntu, Mint, ...) and here for creating .rpm packages (redhat, Fedora, ...).

Related posts: The programming language, The IDE and the libraries, Install NetBeans on Ubuntu 10.04, Java vs .net/C#.

2011-06-27

Windows and the command line

If I remember correctly I was about 14 when I wrote my first MS DOS batch file. I can't say that I write many of them but from time to time I think a VB script is too much for just some little work.

On the other hand I began to really learn Linux shell scripting only about 6 months ago. After that I find the Windows batch file language a very poor thing. It has a poor feature set, a lousy documentation and it is buggy. And this still applies for Windows 2008r2 - so I am talking about the newest OS version.

Right now I lost about two hours investigating a problem to find out that the batch file I wrote, did not work. The problem was caused at a completely unexpected place where I had a few lines that I previously tested separately - on the command line.

Guess what: Behaviour may be different if I run a command on the commandline or from within a batch file!

Here is an example - try this on the command line:
set var1=fluffi
echo _%var1%_ _%var2%_
The result will be: _fluffi_ _%var2%_

And now put those two lines into a .bat or .cmd file and run it.
The result is: _fluffi_ __

A pretty difference, isn't it!

In my case I was passing a string like this "blablabla%muh%bla" as parameter to a called program and the parameter did not fully arrive in the batch file while it did when I tried on the commandline.

What's that?!?! - Is this the Microsoft logic? - I think so... one only has to look at the evolution of MS Word...

Oh - I guess you want a solution: In the batch file you have to escape % doubling it - %%.

Related Post: The Microsoft Logic 

2010-11-14

The future of Java

The last months (after Oracle has completed the merger with Sun) were full of insecurity and discussions within the Java developer communities about the future of Java. Many have blogged about their fears. I personally followed the discussions but I felt, the best thing is to wait. People are so fast with their interpretations and guesses how others will behave.

In parallel there were discussions about Apple stopping support for Java on the Mac etc etc.

Even although Oracle already told they are strongly commited to Java, NetBeans and other famous Sun products, discussions were going on.

Finally a few further commitments have come to public:

IBM joins OpenJDK
http://blogs.sun.com/mr/entry/ibm_to_join_openjdk

Oracle and Apple Announce OpenJDK Project for Mac OS X
http://www.apple.com/pr/library/2010/11/12openjdk.html

This means, that big players decided to go the Java and Open Source path. And it is important to unite the forces. Working together is far better than fighting each other.

When I decided to switch away from my Windows-only-development, one major reason was: There are many other operating systems gaining market share, like several flavors of Linux (Ubuntu, Mint, Redhat, Debian etc) and Apple - and I can't say for sure which ones will be there in the long run, but I want to provide security to my customers, that they can benefit from the software for a long time. - Java was a good choice in the past and now we can again be sure that it still is a good choice. The idea of Java - "write once, run everywhere" - has saved me from a lot of work in the past (compiling for different architectures not required, no building of different styled setup procedures etc). There are people mentioning that the write once, run anywhere phrase is not quite true, because not available for really all operating systems and often there have to be exceptions made for dealing with different operating systems. - Well, this is partly true, when it comes particular features, that might be even not available on all operating systems. Fortunately for such cases Java can be coupled with C(++). For availability: Java is available on more operating systems than most other languages (see http://www.java.com/en/download/manual.jsp).

BTW: C(++) is also a language, that is around and will be around for a long time and I hear nobody complaining that it is developing too slow for example. And I really prefer thinking carefully before putting new features into the language. There must be many things considered. It is important to do no harm to the language.

Oh, there is finally also an official podcast from Oracle for Java developers:
http://blogs.sun.com/javaspotlight/
Of course this is biased and the Javaposse (http://javaposse.com/) is still the first address when it comes to Java podcasts.

We have exact plans for the next versions of Java:
http://blogs.oracle.com/javaone/2010/09/plan_b_wins.html
http://openjdk.java.net/projects/jdk7/features/

And we get exactly what we need next for NetBeans (the first-class Java IDE):
http://netbeans.dzone.com/nb-generate-simpler-rest

Related posts: The dawn after sunset, The programming language, Popular Java myths, Java applications on the desktop, The community.

2010-09-26

Install NetBeans on Ubuntu 10.04

Why should one do a description of installing NetBeans on Ubuntu - it's in the repositories and just a few clicks?

The reason is: Installing it through the repositories you will get problems later when trying to upgrade NetBeans with the builtin-update tool. Apart from this I prefer to download the full package from http://netbeans.org/downloads/index.html and deactivating the modules I do not need - at the moment. I always make sure that the sun (or now Oracle) JDK is installed (there were problems in the past with OpenJDK - and although they should be solved I still go with the Sun/Oracle one.

Preparations:
  • You can install the Sun/Oracle JDK through the repositories or do the manual install.
  • To make sure, the correct Java is used, install galternatives (then available through Applications-System Tools-Alternatives Configurator) and then go through each item in the list on the left. There are quite many Java related tools that - after installing the Sun/Oracle JDK now offer that one as second alternative. For all the Java related tools select the new alternative from Sun/Oracle JDK.
  • If you manually installed new JDKs - e.g. after an update has been released, you might have to change the symlink accordingly at /usr/lib/jvm/java-6-sun using the ln command, eg:
    cd /usr/lib/jvm
    sudo ln -s java-6-sun-1.6.0.20 java-6-sun

So here are my steps for the NetBeans installation:
  1. I create a folder under opt for NetBeans:
    sudo mkdir /opt/netbeans
    I don't use the profile folder for installation because this reminds me too much of Windows. In the profile folder there should only go data and I backup this folder more often than other ones. It does not make sense backup the programs all the time.
     
  2. Then I set the permissions for the normal user:
    sudo chgrp theuser /opt/netbeans
    sudo chmod ug+rwx /opt/netbeans
    If you want to have more users work with NetBeans then replace theuser with a group that all the users are member of - however this solution is only if you trust those users regarding updating and activating plugins etc. Otherwise install as a user with sudo permissions and do not set the permissions above to prevent other users from updating.
     
  3. Then I install all NetBeans components (running the installer as normal user) in that folder (/opt/netbeans). There will be usually a subfolder for netbeans (including version in the folder name) and also for Tomcat and Glassfish.
     
  4. I also extract the javadoc downloaded from http://www.oracle.com/technetwork/java/javase/downloads/index.html into /opt/netbeans as jdk-6-docs or so. In former times I put it under the jdk folder but as I upgrade the JDK itself more often than the documentation this always needed additional work to move the doc to the new folder or change links when they got broken after deleting older javadoc.
     
  5. To make the javadoc available in NetBeans launch NetBeans and go to Tools-Java Platforms, switch to the javadoc tab and add the javadoc root folder - in my case /opt/netbeans/jdk-6-docs.
     
  6. When I add external libraries (Tools-Libraries) I also save/extract them previously to another folder - not within my profile (for reasons I mentioned earlier) - of course an option would be /opt/libs or so - I have a completely different separate folder for shared data and libraries that I backup from time to time (less often than profile data).
Related posts: The IDE and the libraries, The programming language.

2010-09-09

Dynamic method invocation in Java 6

I often read that people are waiting so much for dynamic method invocation promised for JDK 7 (which now is delayed - see Re-thinking JDK7).

What I wonder is: I already use dynamic class loading and dynamic method invocation in Java 6. Of course, it was a little work, but once done the dynamic class loading and object creation is a one-liner and so is the call to a method:

1:  /*  
2:   * DynTool.java  
3:   */  
4:  package at.mwildam.common;  
5:    
6:  import java.beans.Expression;  
7:  import java.io.File;  
8:  import java.lang.reflect.InvocationTargetException;  
9:  import java.lang.reflect.Method;  
10:  import java.net.MalformedURLException;  
11:  import java.net.URL;  
12:  import java.net.URLClassLoader;  
13:  import java.util.Date;  
14:  import java.util.logging.Level;  
15:  import java.util.logging.Logger;  
16:  import javax.tools.JavaCompiler;  
17:    
18:    
19:  /**  
20:   * Dynamic class loading and method invocation  
21:   * By Martin Wildam (http://www.google.com/profiles/mwildam)  
22:   * @author Martin Wildam  
23:   */  
24:  public class DynTool  
25:  {  
26:    /**  
27:     * Tries to instanciate an object of the given class and returns a pointer to it.  
28:     *   
29:     * Expects the class files in the directory given by the  
30:     * dynClassPath parameter. For each dot (.) in the class path there  
31:     * must be given a subfolder. If there exists a .java file instead of  
32:     * the expected .class file then the method tries to compile the .java file.  
33:     * It tries also a compile if both the .java and the .class file exists but  
34:     * the .class file is out of date (older than the .java file.  
35:     * The addClassPath parameter is only used if the attempt to  
36:     * compile is done.  
37:     *   
38:     * You can also specify a jar file in the dynClassPath parameter if  
39:     * you have a fully compiled and prepared package.  
40:     *  
41:     * Returns null if the object could not be created.  
42:     *   
43:     * Sample: getPluginInstance("/Work/Java/TestGUI/dist/TestGUI.jar", "testgui.TestPluginClass", "/Work/Java/TestGUI/dist/lib")  
44:     *   
45:     * Note: Dynamic class loading and calls evaluated during runtime  
46:     * using reflection is time consuming in general and therefore should be  
47:     * avoided for performance citrical operations (although already better  
48:     * since Java 5).  
49:     *   
50:     * We are returning null here in error case although not recommended  
51:     * because I do agree with Joel Spolsky (http://www.joelonsoftware.com/) on  
52:     * Exceptions at http://www.joelonsoftware.com/items/2003/10/13.html.  
53:     *  
54:     * @param  dynClassPath path to classes root dir where to search for the class to instantiate.  
55:     *     Can also be a .jar file.  
56:     * @param  className Full class name for the plugin class to use.  
57:     * @param  addClassPath is an additional option for classpath to search (;-separated)  
58:     *     which is only used when a compile attempt is done.  
59:     * @return Object or null in error case.  
60:     */  
61:    public static Object getPluginInstance(String dynClassPath, String className, String addClassPath)  
62:    {  
63:      if (!dynClassPath.toLowerCase().endsWith(".jar"))  
64:      {  
65:        String classFile = className.replace(".", "/");  
66:        classFile = dynClassPath + "/" + classFile;  
67:        String javaFile = classFile;  
68:        javaFile += ".java";  
69:        classFile += ".class";  
70:        if (addClassPath.length() != 0) addClassPath = ";" + addClassPath;  
71:    
72:        if ((!existsFile(classFile) && existsFile(javaFile))  
73:            || getFileDate(classFile).before(getFileDate(javaFile)))  
74:        {  
75:          JavaCompiler jc = javax.tools.ToolProvider.getSystemJavaCompiler();  
76:          int r = jc.run(null, null, null, "-classpath", dynClassPath + addClassPath, "-d", dynClassPath, javaFile);  
77:          if (r != 0) return null;  
78:        }  
79:      }  
80:      else  
81:        addFileToClassPath(dynClassPath);  
82:    
83:      try  
84:      {  
85:        if (addClassPath != null && addClassPath.length() > 0)  
86:          addFilesToClassPath(addClassPath);  
87:        URL url = new URL(DynTool.getUrlFromPath(dynClassPath));  
88:        URL[] clsList = new URL[1];  
89:        clsList[0] = url;  
90:        URLClassLoader ucl = new URLClassLoader(clsList);  
91:        Class cls = ucl.loadClass(className);  
92:        return cls.newInstance();  
93:      }  
94:      catch (NoClassDefFoundError ex)  
95:      {  
96:        Logger.getLogger(DynTool.class.getName()).log(Level.SEVERE, null, ex);  
97:        return null;  
98:      }  
99:      catch (ClassNotFoundException ex)  
100:      {  
101:        Logger.getLogger(DynTool.class.getName()).log(Level.SEVERE, null, ex);  
102:        return null;  
103:      }  
104:      catch (InstantiationException ex)  
105:      {  
106:        Logger.getLogger(DynTool.class.getName()).log(Level.SEVERE, null, ex);  
107:        return null;  
108:      }  
109:      catch (IllegalAccessException ex)  
110:      {  
111:        Logger.getLogger(DynTool.class.getName()).log(Level.SEVERE, null, ex);  
112:        return null;  
113:      }  
114:      catch (MalformedURLException ex)  
115:      {  
116:        Logger.getLogger(DynTool.class.getName()).log(Level.SEVERE, null, ex);  
117:        return null;  
118:      }  
119:    }  
120:    
121:    
122:    /**  
123:     * Late binding method call on an already instantiated object.  
124:     *   
125:     * Invokes the requested method of a given object instance where the  
126:     * object class is not specified at compile time.  
127:     *   
128:     * To call a method that does not have a parameter then pass null for the  
129:     * params parameters.  
130:     *   
131:     * What the method returns is routed to the caller of this method as Object  
132:     * so you have to cast the return type to something more specific if needed  
133:     * or just use .tostring. If the called method is declared void then this  
134:     * method returns null.  
135:     *  
136:     * Note: Dynamic class loading and calls evaluated during runtime  
137:     * using reflection is time consuming in general and therefore should be  
138:     * avoided for performance critical operations.  
139:     *   
140:     * We are returning null here in error case although not recommended (because  
141:     * of the earlier mentioned reasons).  
142:     *  
143:     * @param  instance A not well known object for that we hope to be able to  
144:     *     call the requested method.  
145:     * @param  methodName Name of the method to be called  
146:     * @param  params parameter objects to pass to the method (best matching declaration variant is searched)  
147:     * @return Returned object or null if method is declared void or an error occurred.  
148:     */  
149:    public static Object call(Object instance, String methodName, Object... params)  
150:    {  
151:      //Statement stmt = new Statement(obj, methodName, null);  
152:      //stmt.execute();  
153:    
154:      Expression expr = new Expression(instance, methodName, params);  
155:      //expr.execute(); //Not necessary, called automatically on getValue();  
156:      Object result = null;  
157:      try  
158:      {  
159:        result = expr.getValue();  
160:      }  
161:      catch (Exception ex)  
162:      {  
163:        Logger.getLogger(DynTool.class.getName()).log(Level.SEVERE, null, ex);  
164:      }  
165:      return result;  
166:    }  
167:    
168:    
169:    /**  
170:     * Adds a resource given as URL to the classpath.  
171:     *   
172:     * Adds the given url to the classpath dynamically.  
173:     *   
174:     * From antony_miguel at  
175:     * http://forums.sun.com/thread.jspa?threadID=300557&start=0&tstart=0:  
176:     * "  
177:     * I've seen a lot of forum posts about how to modify the  
178:     * classpath at runtime and a lot of answers saying it can't be done.  
179:     * I needed to add JDBC driver JARs at runtime so I figured out the  
180:     * following method.  
181:     *   
182:     * The system classloader (ClassLoader.getSystemClassLoader()) is a subclass  
183:     * of URLClassLoader. It can therefore be casted into a URLClassLoader and  
184:     * used as one.  
185:     *   
186:     * URLClassLoader has a protected method addURL(URL url), which you can use  
187:     * to add files, jars, web addresses - any valid URL in fact.  
188:     *   
189:     * Since the method is protected you need to use reflection to invoke it.  
190:     * "  
191:     *   
192:     * The class path change does not reflect in the system property  
193:     * "" because that property does not get modified any more after application  
194:     * start. So don't check success by checking  
195:     * System.getProperty("java.class.path");.  
196:     *  
197:     * @param  url Url to add to the class path.  
198:     * @return True if operation was successful  
199:     */  
200:    public static boolean addUrlToClassPath(URL url)  
201:    {  
202:      if (url == null)  
203:      {  
204:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, "Missing url to add to classpath.");  
205:        return false;  
206:      }  
207:    
208:      boolean b = false;  
209:    
210:      URLClassLoader sysloader = (URLClassLoader) ClassLoader.getSystemClassLoader();  
211:      Class sysclass = URLClassLoader.class;  
212:      try  
213:      {  
214:    
215:        Class[] methodParams = new Class[1];  
216:        methodParams[0] = URL.class;  
217:        //There could be really different classes in the array.  
218:        @SuppressWarnings("unchecked")  
219:        Method method = sysclass.getDeclaredMethod("addURL", methodParams);  
220:        method.setAccessible(true);  
221:        method.invoke(sysloader, new Object[]  
222:            {  
223:              url  
224:            });  
225:        b = true;  
226:      }  
227:      catch (IllegalAccessException ex)  
228:      {  
229:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, null, ex);  
230:      }  
231:      catch (IllegalArgumentException ex)  
232:      {  
233:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, null, ex);  
234:      }  
235:      catch (InvocationTargetException ex)  
236:      {  
237:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, null, ex);  
238:      }  
239:      catch (NoSuchMethodException ex)  
240:      {  
241:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, null, ex);  
242:      }  
243:      catch (SecurityException ex)  
244:      {  
245:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, null, ex);  
246:      }  
247:    
248:      return b;  
249:    }  
250:    
251:    
252:    /**  
253:     * Converts a file path to an url link.  
254:     *   
255:     * Returns the url link equivalent to the given path as string.  
256:     *  
257:     * @param  path  
258:     * @return Url string  
259:     */  
260:    public static String getUrlFromPath(String path)  
261:    {  
262:      try  
263:      {  
264:        return new File(path).toURI().toURL().toString();  
265:      }  
266:      catch (MalformedURLException ex)  
267:      {  
268:        return "";  
269:      }  
270:    }  
271:    
272:    
273:    /**  
274:     * Returns a boolean true if a "normal" file with the specified name exists.  
275:     *   
276:     * Note: Returns false for files that are part of the kernel system.  
277:     * So it returns true only for "normal" files.  
278:     *  
279:     * @param  fileFullName FQPN of the file to be searched for  
280:     * @return Boolean  
281:     */  
282:    public static Boolean existsFile(String fileFullName)  
283:    {  
284:      if (fileFullName == null)  
285:        return false;  
286:      else  
287:      {  
288:        File f = new File(fileFullName);  
289:        return f.exists() && f.isFile();  
290:      }  
291:    }  
292:    
293:    
294:    /**  
295:     * Returns the timestamp of the file with the given name if exists otherwise 0.  
296:     *   
297:     * Returns a Date of 0 if the file could not be found otherwise the last  
298:     * file modification date.  
299:     *  
300:     * @param  fileName Name of the file from which to read the date and timestamp  
301:     * @return Date  
302:     */  
303:    public static Date getFileDate(String fileName)  
304:    {  
305:      if (!existsFile(fileName))  
306:        return new Date(0);  
307:      else  
308:      {  
309:        File f = new File(fileName);  
310:        return new Date(f.lastModified());  
311:      }  
312:    }  
313:    
314:    
315:    /**  
316:     * Adds the given file dynamically to the class path.  
317:     *   
318:     * Further details see {@link #addUrlToClassPath(java.net.URL) }.  
319:     *  
320:     * @param  file File object to be added dynamically to the class path.  
321:     * @return True if operation was successful.  
322:     */  
323:    public static boolean addFileToClassPath(File file)  
324:    {  
325:      if (file == null)  
326:      {  
327:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, "Missing file to add to classpath.");  
328:        return false;  
329:      }  
330:    
331:      URL url;  
332:      try  
333:      {  
334:        url = file.toURI().toURL();  
335:      }  
336:      catch (MalformedURLException ex)  
337:      {  
338:        Logger.getLogger(DynTool.class.getName()).log(Level.WARNING, null, ex);  
339:        return false;  
340:      }  
341:    
342:      return addUrlToClassPath(url);  
343:    }  
344:    
345:    
346:    /**  
347:     * Adds the given file dynamically to the class path.  
348:     *   
349:     * Further details see {@link #addUrlToClassPath(java.net.URL) }.  
350:     *  
351:     * @param  fileName FQPN of the file object to be added dynamically to the class path.  
352:     * @return True if operation was successful.  
353:     */  
354:    public static boolean addFileToClassPath(String fileName)  
355:    {  
356:      return addFileToClassPath(new File(fileName));  
357:    }  
358:    
359:    
360:    /**  
361:     * Adds files in the given folder dynamically to the class path.  
362:     *   
363:     * You can specify multiple paths separating them by ";".  
364:     * Further details see {@link #addUrlToClassPath(java.net.URL) }.  
365:     * Path must contain only jars and class files (subfolders not included).  
366:     *  
367:     * @param  path FQPN of the path to be added dynamically to the class path  
368:     *     or multiple paths separated by ";".  
369:     * @return Number of jars and class files added.  
370:     */  
371:    public static int addFilesToClassPath(String path)  
372:    {  
373:      if (path == null || path.length() == 0) return 0;  
374:      int n = 0;  
375:    
376:      if (path.contains(";"))  
377:      {  
378:        String[] subPaths = path.split(";");  
379:        for (String subPath : subPaths)  
380:        {  
381:          n = n + addFilesToClassPath(subPath);  
382:        }  
383:      }  
384:      else  
385:      {  
386:        File dir = new File(path);  
387:        File[] contents = dir.listFiles(); //Path Must contain jars and class files only  
388:        for (int i = 0; i < contents.length; i++)  
389:        {  
390:          File file = contents[i];  
391:          if (addFileToClassPath(file))  
392:            n++;  
393:        }  
394:      }  
395:      return n;  
396:    }  
397:    
398:  }  
399:    
400:    

You might prefer looking at this code on pastebin.

Sample usage:
  1. Object obj = getPluginInstance(yourJarFile, yourPluginClassName, additionalLibPath);
  2. Object result = call(obj, "pluginMethod", param1, ...);
    // For no parameters use at least null for param1
I use this currently in two cases:
  • For loading plugins at runtime (in those cases I only need getPluginInstance because I cast the object to a known interface class).
  • To avoid fixed dependencies of common utility libraries (in those cases I only need the call method). What I mean with this? - To explain, a little example: I have a Swing utility class that runs through all elements of a JFrame or JDialog and returns a map with all widget names and values it can extract. This way, saving dialog inputs is a one-liner. However, I support a lot of different external widgets, most are not used in 80% of my projects, so I don't want to introduce the dependencies to all those external components not included in the Swing core. Using the dynamic call offers the support for those widgets when I find them in dialog contents (identified by class name) where they occur. And the appropriate dependencies are only needed in the particular projects where they are needed.
So I don't really understand, why so many people are arguing against Java, that dynamic calls are not possible - where my sample code either automatically compiles a class that is given as .java instead of packed into a compiled .class or .jar file. And if I have both I check the class file if it is older and compile only in that case. So I would say, this is dynamic Java language!

Related posts: Get reliable local IP address in Java, Popular Java myths.

2010-06-24

Popular Java myths

After developing more than 10 years mostly in Visual Basic (classic), VB Script, VBA etc I started moving to Java after a long evaluation period of different languages about 2 years ago (see also "The programming language") .

Since then when talking with customers, .NET people and even Java folks people come across again and again with the same arguments against Java that are simply wrong. After discussing and researching these arguments a lot of times I am really tired of explaining so this post will hopefully save me from that in the future.

BTW: In discussions you have to distinguish between the Java as a platform (JVM) or the Java language. There are a lot of other languages like Scala, Groovy, JRuby (Ruby interpreter) or Jython (Python interpreter) and others. That the JVM is very popular and far from being dead is not taken into doubt by most people, not so for the Java language.

But why don't these Java language myths finally die:
  1. Java is dead.
    The argument usually comes from the fact that a long time passed since the last major release (Java 6 Update 20 is current at this time) and that they don't see big new stuff coming. At this point have you ever considered C(++) dying? - Or Microsoft Windows? No big changes for many years there either!
    There are other languages that evolve very fast - but take into consideration that most of those languages are very new in relation to Java and there is still much work to be done. Of course with evolution of a language there is legacy generated and it gets more difficult to introduce major new stuff. The newer languages will see the same happening as these problems affects any software getting into age.
    But: It means, Java is proven and stable and I am happy that the language is not changed or enhanced by running after hypes. I really like the decision to think well before really changing a big thing (like introducing closures).
    Another reason why people told Java to death is citing the TIOBE or other indexes showing Java loosing popularity or market share. If you examine how these statistics are built you always find that they are not complete and just investigate a few parameters (like new items in Google search results for example). When I heard the last discussion about TIOBE, Java has fallen on position 2 behind C - now it is back on top again although - according to TIOBE - it still looses popularity (which is logical to me because a lot of new other languages are running on the JVM attracting especially Java developers). On the other hand tht C# is gaining, does not necessarily mean that it is better than Java. Windows developers didn't get major new stuff for about 10 years and basically Microsoft is telling them to move.
    And it remains the question if new is always better, a lot of companies heavily rely on the stability of Java and the long-term return on investment (ROI).
    Besides, although people say, Java is dying, there is so much daily news on Java that I simply can only follow the biggest news. Java land is soooo large and the community is so huge.
    Last but not least: Because there are more operating systems around than ever, platform independent development is getting more important (as developing separately for each platform is costly) - well this is a plus for all languages based on the JVM.
  2. Java is slow.
    There are 3 groups of people saying this. The first group is talking about the startup times and the second is comparing with C(++).

    Regarding the first group: These are mostly people on Windows using Java applications just occassionally. Yes, the JVM takes a while to load (which BTW should be addressed in Java 7) but this applies also for the .NET runtime or other big libraries used in other big applications. The point is, that Windows tends to load everything Windows-related already on Windows startup and if an application using the .NET runtime already then of course the next application will start faster. This issues is (at least partly) already addressed because some Java update comes with an autostarter that also loads the JVM at login time. And BTW: Java 6 is much faster than Java 5 and Java on Linux is much faster than on Windows.

    Regarding the second group: They usually refer to optimized C(++) code. First to say, most developers do not really performance optimize their code (only when necessary); second, in a lot of cases, performance of the language is not the bottleneck (usually network and HDD speed is - or inefficient algorithms/storage methods) and third, the optimization is done at compile time and at runtime. Runtime optimization is not available for C(++)-programs. So it can happen, that Java is even faster than C(++). But of course, in a lot of cases particular optimizations are written in C(++) and then called from Java to improve the overall performance. Of course, C(++) has the potential to be faster than Java. The write once, run everywhere idea introduces a level of abstraction that surely can affect performance - there is no gain that does not introduce a cost somewhere else. But: For most performance issues the performance of the language itself is irrelevant (I mentioned the real bottlenecks above)! Further, I only met once a C(++) developer who really considered performance on everything he did. Anyway, just because C(++) tends to be the fastest of all programming languages, Java is not slow - Java is faster than most other languages! - See e.g. benchmarks at alioth.debian.org.

    Regarding the third group: Those are usually comparing some simple PHP application with some Java EE application that makes use of a component stack that I just get sick when I see it - so no wonder if such a monster app is behaving a little lethargic. Although Java is widely used in the EE world in huge environments, a real lot of connections and a huge amount of data with a huge component stack and a lot of legacy code (and sometimes even still on Java 4 or 5), Java could be used in smaller environments too. Let's say, a typical PHP application contains a lot of DB queries, XML/JSON/HTML parsing and HTML generation. This could be easily done with plain Java also without introducing any particular framework. So most of those people are simply comparing apples with bananas. See also benchmark mentioned before where PHP rates really bad. - That said, according to earlier mentioned real bottlenecks, that does not really matter in most cases.
  3. Java applications need longer time to develop.
    Well, this is maybe not a myth, but a tendency. It is true that while a Ruby-Developer might already have finished the task, the Java developer might still be evaluating the right framework and library to use. But this is not due to the language itself. In many other languages you have not the choices you have in Java land. And for development on Windows, many people just rely on the recommendations given by Microsoft. My experience, after I got member of the local JUG and met some Java developers elsewhere at conferences is, that there are really smart people doing awesome stuff and working on big and critical projects and such with product lifetimes beond 10 or even 20 years. Of course this involves a big responsibility and therefore I can see Java developers investing more time into the evaluation of the architecture, used frameworks and libraries and algorithms.
    And this does not mean that you can't get a small project quickly up and running the "agile style" (using the libraries and frameworks you are already familiar with without starting to evaluate with Adam and Eve).
    Example: Lately I needed a little tool to count all PDF pages of all PDF documents in a certain tree structure (to evaluate needed license volume for OCR processing). In about an hour I had a small tool ready. I was sure, that there exists a tool already that I could use but searching the internet + testing would have been similar amount of work. And if I would have done it with VB on Windows only half an hour for just building a setup that installs the application at client side - but in Java I simply sent the built jar by email and finished. Just run it without the need to install. As another example it took me about 4 days for a prototype of a PDF archiving tool in Swing with embedded PDF viewer and fulltext indexing of the PDF content. Of course this would not have been possible without any experience in Java - any language must be learned first to get really productive. I have a friend who wondered about the long time I spent on evaluation when starting with Java. Yeah, I already can choose between at least 3 great free (see comparison at Wikipedia) Integrated Development Environments (IDE) while on Windows I only have 1 free for .NET in best case (because the most obvious choice here is the costly Visual Studio). Then for thick clients I can choose at least between SWT or Swing for GUI (not to talk about the plenty of choices for web applications). Then there are plenty of logging frameworks and so on. But once you have chosen your preferred toolset, you can use that also if it might not fit 100% best for the next project y after finished project x. And BTW: You could rely on the recommendation of others (if you want to rely on me use NetBeans and/with Swing for thick clients). I myself did not have the appropriate contacts so I went the rocky way.

Related posts: Java applications on the desktop, The programming language, The IDE and the libraries, The dawn after sunset, Dynamic method invocation in Java 6, The future of Java.

2010-01-23

Web application security

Today I noticed this video: "Clickjacking".

I have no idea how it is done but it shows one more time that web applications are not the overall optimum solution for every development.

If such things are possible, then there are serious risks in using web applications for accessing critical,confidential data!

Is it so much more difficult to download and launch a jar file by double click? Deployment is not necessarily complicated as not every application needs a complex and high sophisticated setup process. ;-)

Related posts: Web vs thick client, Your holy machine.

2010-01-04

New Year's IT resolutions

As far as I read on forums it has been already a lot of times that people told that next year will be the year when Linux breaks through on the desktop. And the first discussions I found about being 2010 being the year of Linux already have been from 2007.

My opinion is: 2010 will not be the year's revolution that Linux will break through on the desktop.

The reason is: Most people do realize now, that many things sucks as they are evolving lately:
  • People need to buy the operating system for new (even if they were completely fine with the old one) when they buy a new PC (because hardware comes along with a OS license already included).
  • People can't reinstall their OS for new because the installation CD somewhere got lost or they notice that there was no CD shipped with their notebook only after the HD crashed.
  • People use more and more "standard software" which costs more and more money.
  • Installation of program B is corrupting installation of program A.
  • Computer getting slower and slower over time.
  • Computer getting unstable over time.
  • People notice that proprietary file formats force them to buy expensive software (upgrades) and that these formats are risky for long time archiving.
  • ...
There is basically one root issue: Vendor Lock-in! - Companies tend toward trying to bind the customer to their products and services.

During the last year I was asked more often than ever if it would be a good idea to switch from Windows to Mac. This is an indicator for me that that people's satisfaction with Windows is somehow fading away. But Apple is not the solution in my point of view. The only real alternative I do see is Linux. Why? Although there are (mostly) companies behind different flavors of Linux (the Linux distributions), the core is everywhere the same and the general philosophy is similar - e.g. to endorse Open Source, open standards and the GPL. With Linux you have the widest freedom and least vendor-lockin.

But why can't be 2010 be the year of success? - It's because of the vendor lock-in a switch usually can't be done easily and quickly. This has to be well planned and there must be a step-by-step implementation!

I started years before my switch to prefer open standards and open source software. So at the final switch I was already familiar with the most new applications, as I used Firefox, Thunderbird, Open Office, VLC, GIMP and many others already under Windows.

For a company that is considering a switch or either is just unsure about the IT future this means:
  • Save data in an open standard format (e.g. EML instead of MSG, ODT or RTF instead of DOC and so on).
  • Prefer to buy and/or use software that is available on different platforms (Open Office instead of Microsoft Office is a big candidate here).
  • When investing in new software development plan a platform independent solution.
These are considerations and policies that prepare you for a change and will bring you more long term safety of your investment (and hence higher ROI). However, all the changes that need to be implemented cannot be done over night!

The journey to the future happens on a road that you don't know yet. Will you rather buy a car that just runs fine on asphalt or one that works fine on a rocky road also? - So is with software. Using the platform independent solution you are better.

Related posts: Going Linux, Cross-platform solutions, Software on speed.