10.09.07

A Java Surprise

Posted in boggle, programming at 11:44 pm by danvk

I’ve always been a Java and Eclipse naysayer, but I’m afraid new experiences are forcing me to reevaluate my skepticism. The last time I used Java was JDK 1.3 on a Sparc workstation back in early 2004. Eclipse was hella slow on that hardware, and somehow my workspace wound up in a temporary directory. This was a very bad thing, because as soon as I logged out, my project was gone forever. So I had good reason to swear off Eclipse.

More generally, Java left off a mighty stink back in 2004. Any GUI that I ran on the Mac would look out of place and felt clunky. Performance was poor. But in retrospect, I suspect much of the rank Java smell was really coming from the design patterns gibberish I was being force-fed at the same time. Why use a simple array when you could use an AbstractListFactory that does the same thing with 10x code bloat?

Regular readers only get one guess what program I wrote to get in the swing of things.

The C++ code translated almost line-for-line to Java. Most of the changes were either syntax (“->” to “.”) or swapping String for char*. It took a while to remember that everything is a pointer in Java. The Java statement Trie t = new Trie(); is the equivalent of C++’s Trie* t = new Trie; and not plain old Trie t;, which uses the stack. Another major pain was the lack of unsigned types, which I used as hash codes in some tests.

Here’s the Java code, for those interested. I expected Java code to be an order of magnitude slower than the equivalent C++, so this initial benchmark surprised me:

C++:  Evaluated 21632 boards in 0.694 seconds = 31,162 bds/sec
Java: Evaluated 21632 boards in 1.108 seconds = 19,523 bds/sec

That’s only a 37% performance penalty, far less than the 90% or more I was expecting. Since my code doesn’t create/destroy any objects during the critical section, I’m really testing the effectiveness of the JIT. Since this code is a direct C conversion, it makes sense that it does well.

I don’t understand the internals of Java well enough to know how valid my benchmark is. Profiling C++ code is relatively straightforward, since nothing is going on behind your back. Not the case with Java. For example, does that 1.108 seconds include the time it took the JIT to compile my code? That might explain the whole perf difference. Also, am I fully optimizing? I hear there’s a difference between the client and server JITs. Which one am I using? How can I tell? Lazyweb?

A few more thoughts on the whole experience:

• Eclipse is just great, especially for someone whose knowledge of the JDK is rusty. Having “string.” bring up a list of methods was great. This was less useful for more obscure Java-isms, like System.getProperty("user.dir") to get the current working directory.
• When Eclipse spots an error in your code, it suggests a solution, which you can double-click to perform. This was just perfect for a rusty coder. It added lines like import java.io.File; to my code, which would have taken me a while to figure out on my own. That’s always a nuisance in C++.
• I can’t figure out what command line Eclipse is using to run my code. I have no idea how it’s running my unit tests. Is there any way of finding this out?
• jUnit was very easy to use inside Eclipse. I particularly liked the ability to write unit tests inside the class they were testing. Just tag a method with @Test and it becomes a unit test. Very cool.
• I found the whole StringBuilder business pretty clunky. Writing "a" + "b" is special kludge for new StringBuilder().Append("a").Append("b").toString(). I also missed printf when writing to stdout. Is there no natural way to mix numbers and strings?
• Java GUIs on the Mac still aren’t quite there. When I moused over the icons in Eclipse, there was noticeable flicker.

A tool like Eclipse is a great boon in understanding a large, foreign code base. One thing I’ve discovered in my past year at Google is that, while I’ve become a fairly good coder through experience, I have almost no external experience working with other people’s code. Make no mistake, navigating other people’s code is a skill. And to a surprising extent, it’s a skill disjoint from coding itself. We have a few tools to help with this at Google, but nothing quite so low-latency as what Eclipse pops up when you press type a period. The possibility of tools like Eclipse is a strong argument for languages with a simple syntax. When anyone can parse a language, they can build amazing tools like this one.

Permalink