Java users know all of the advantages of using Java over C or C++. If you've forgotten, here are a few off the top of my head:

• An extremely rich set of libraries within the JDK and in the open source community
• Ease of programming and very strong IDE support
• Portability
• Native I/O speeds with the NIO package
• Huge industry investment in JVM technology
• Did I mention rich IDE support - once you've used NetBeans or Eclipse, who wants to go back to vi

But of course we always have the old argument of Java being too slow. For many years, that was a valid point. But no longer. Then along came JIT, NIO and GC improvements in release after release. Even in our benchmarking, we have seen several percentage increases in performance by moving to the latest version of the JVM.

One argument that a friend of mine, who would rather write in assembly code (or C if he has to ;-) has made is this: with Java you are a step removed from the O/S and so the hardware. His problem with Java is you lose some control. Within the context of the Java multi-core world, his argument focuses on the inability to build affinities between threads and possibly lose performance since threads that may be sharing data in cache would be better off in the same core-set of a processor. Doing so would prevent not only cache thrash, but also prevent "long" accesses to memory. These long accesses are due to the non-uniform memory architecture (NUMA) of most multi-core processors. For a good explanation of NUMA and experiments with thread affinity, please reference this blog post.

Of course, my friend has a point. With Java, you are a step removed from controlling the underlying O/S and hardware. However, that is not always a bad thing. As I mentioned in the list of the positives of using Java, JVM technology has been a major investment target for several large computer and software vendors for years. Each release of the JVM has increased performance and added more functionality. Just look at what Azul Systems has been doing in the area of JVM technology. It is fascinating to watch and great to be able to take advantage of all that advanced research. Reference the interview with Cliff Click from Azul for more detail.

I have to admit there are times I would like more control over things like memory and resource management in Java! Just give me a destructor method and I'd be happy. Ok, maybe not. Especially since I've made the mistake of re-factoring Java code using some of my C++ optimization tricks just to find the compiler was already one step ahead of me. It had already optimized out my String objects.

Which leads me to my point. Using Java, I am most likely leaving some performance on the multi-core table, so to speak. If I dropped down to C/C++ I could utilize low level thread methods to turn on CPU (and core) affinity to eke out a few more percentages of performance, possibly. This type of optimization is easiest made with a known algorithm and is not generally applied to a Java multicore framework such as DataRush. As such, I'm willing to take what is arguably a small hit in performance to reap all of the strong benefits of Java. Looking at what Azul Systems, Sun, IBM, JRockit and others are doing in the JVM technology arena gives me confidence that Java will continue to be the right choice for DataRush for years to come.