Clearing up some common Java misconceptions.
Slashdot recently ran a story about the early release version of a Java 6 SDK from IBM. Reading through some of the comments to that story, I noticed that a number of them mentioned some common misconceptions about Java that I think we need to clear up. Having used Java for quite some time now, in a variety of client and server-side environments, I think we can get these misconceptions cleared up pretty quickly.
The first misconception can be stated as: “All slow Java code is written by poor programmers.” That’s the attitude that this posting takes. Of course, that’s a completely incorrect assertion to make. I think NetBeans and Eclipse are excellent examples of how Java code can be written by quite experienced developers, and still be rather slow. Those applications are not enjoyable to use, even on fast, modern systems with sufficient memory. This point was made quite clear in a response to the post that made the misleading claim. Swing tends to be the main problem for NetBeans, while Eclipse suffers from extreme levels of bloat. Many other client-side Java applications, even those written by very experienced and talented developers, suffer from performance issues due to Swing and the inherent bloat of Java and the Java class library.
Another misconception is that Java is a compiled language, as is claimed by this posting. I do not consider compilation to bytecode to be comparable to compilation to machine code, which is the traditional meaning of “compiled language”.
The only way we can consider Java to be a compiled language is if we specifically state that we’re using a native code compiler like GJC to compile our Java application. Otherwise, Java as used with the existing VM-based Java environments can not be considered a compiled language. It’s best to consider it to be interpreted. Python uses a similar scheme, with the programmer-editable source code being compiled to a bytecode representation when first run through the Python interpreter. And most of us would not consider Python to be a compiled language.
A third misconception involves the suggestion that Java applications are “fast”. Fast is one of those words that can have different meanings when being used to describe a computer program. For client-side applications, it often refers to responsiveness. On the server-side, it can refer to throughput. And I think Java has real trouble when it comes to both meanings of the word “fast”.
This posting makes some great points regarding the speed of Java applications. Most client-side Java applications, especially those using Swing, are noticeably unresponsive compared to native applications written in a language like C++. Even client-side Java applications using SWT, IBM’s Java binding to various native toolkits, tend to be slow. That posting mentions RSSOwl, a feed reader built upon Java and SWT. From my experience using it, I found it to be painfully slow, especially compared to a native program like Akregator.
When used for server applications, Java’s performance problems are often dealt with via the use of more powerful hardware. Yes, it is often true that any speed issues can be dealt with by throwing a greater amount of more powerful hardware at the problem. But that’s not a financially viable solution for many smaller and medium-sized businesses, especially ones who want to reuse their existing hardware for new Java-based applications. Often their only way to avoid the performance issues of Java is to avoid Java-based systems altogether.
I’m not sure why so many misconceptions about Java still exist. We’ve been using it for a long time by now, and many issues that were present a decade ago are still present today. So let’s keep in mind some simple things: poor-performing Java code can be written by anyone, client-side Java applications are often very unresponsive, and Java is not a compiled language.
February 3rd, 2007 at 11:38 pm
[…] A while back I wrote an article clearing up several popular Java myths. One such myth is that Java can be considered a “compiled” language. It seems that a link to my article was submitted to Reddit, and one of the comments there concerned this very issue. This is a topic I would like to address further. […]