Why Java?

I'm guessing lots of folks will question my decision to implement Opal in Java. I won't go overboard to defend my decision, but I do think it's worth explaining myself.

Q: Why consider switching from C to Java?

A: It's a lot easier (for me) to correctly implement an algorithm (and the program that wraps it) in Java. That's because there's less complexity to memory management, and also because the tools available for writing and testing Java programs provide (in my opinion) vastly superior support to the coder.

Q: But Java is too slow to use in fast scientific software! What are you thinking?

A: What I'm thinking is that it's not all that slow, really.

Before going down this path, I found that there's plenty of evidence that Java programs written with speed in mind (read: not using a ton of objects) can compete quite nicely with the speed of programs written in C.

For a hint of the evidence that convinced me to give it a try, see:

OK, so Java-lovers tell us that Java is fast. I was intrigued, but not convinced. How to convince myself? Do my own test. I did, reimplementing the original C code for Opal (and the subpackage, alignalign) in a new Java application.

I omit all details here, and hope you'll believe that the test was as fair as I could make it. The C program was built to be as fast as possible, given algorithmic constraints (e.g. using memory pools to avoid malloc overhead).

With esentially identical algorithms, the Java implementation ran about 10% slower than the C implementation (on average) over a wide range of inputs and several computers. Given the implementation and portability benefits that come with using Java, that was close enough for me.

(update: 01/11/2011)

It is worth noting that in the three years since releasing Opal, I've identified at least three reasons not to implement an application in Java:
Travis Wheeler