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.