Don't whine about Java being slow

I came across the article Java is too slow! via The Server Side today. I think most Java programmers in the late 90's and early 00's have seen one Dick or the other in their career. I made a post there on why you can't whine about Java being slow and thought of expanding on that here.

I think Java got a bad rep mainly becuase of yuppie programmers (and yes, many from India with more interest in catching on to the next wave than learning fundamentals of programming) spewing out junk code. The big firms were no exception either. I vividly remember IBM's Visual Age for Java, the pre-cursor to the now popular Eclipse - a kludgy, super-slow IDE that made users cringe and forced them away from Swing and over to writing web apps for desktop systems.

I have implemented a number of highly transactional systems as well as GUI applications (yes, Swing) in Java that have run extremely fast. The top reasons I have found for Java being slow are Lack of application of fundamentals of programming (such as taking care of the number of objects you create). Spring to some extent reduces this risk, if used correctly. The impact is the highest in Swing applications where layouts are nested too much just because someone didn't spend enough time to do the design properly. In some cases, even moving some unwanted "new"s out of loops will help things significantly. Not using the right software and instead reinventing the wheel. I have used MQ Series for a distributed system that happily processed around 100,000 records or more per hour without any complaints. The average transaction was around 7ms. And it was all written in Java. Not using threads optimally. One program that used the Java Advanced Imaging packaged processed and uploaded 50,000 images (each image around 200K) per hour easily when multiple threads were used (you have to of course check how many threads are optimal). Not using a profiling tool to check your code. In the glory days of Borland, I used their OptimizeIt software - an excellent tool to detect object leaks, something that's ignored due to Java's garbage collection. Finally, not tuning the JVM. After optimizing your code, you need to tune the GC so that it works for your application. Just leaving the defaults as they are (or just modifying the ms/mx values doesn't cut it). It's like expecting an auto-gear car to win in a drag race. I am sure there are a number of other reasons I can come up with, but these 5 tend to be the most common. It looks like Java itself succumbed to the slowness by creating stupidities such as the original J2EE, where there was way too much architecture/framework and way little code. Thankfully, the open source community - with Spring, Hibernate, and others - seem to have brought some sanity back and hope it continues before another wave of stupidity (possibly int he form of overuse of annotations) sets in.