Why/Why Not Java
I’ve had an on-again, off-again relationship with Java. It always appealed to me: it runs on every platform without modification (particularly if you’re not dealing with a GUI); since the invention of JIT compilers, it’s basically as fast as C/C++, and faster than Objective-C; and its syntax is like C++, only way less convoluted.
Still, a couple years ago, I probably wouldn’t have decided to do EcoGillespie in Java. Back then, Java had this weird hybrid between static and dynamic typing. Where this caused me trouble was with collections, primarily: you could put any kind of object you wanted into a collection (good general feature of collections!) but, because the Java compiler enforces type-checking strongly, when you pulled that object out of the collection, you had to manually cast it to the correct type. (The “correct” way to do something like that is to actually CHECK its type using the instanceof operator when you pull it out of the collection. But I’m talking about cases where you NEVER put anything other than one type of object into a particular collection.) In C++, there’s this abomination called templates, where the compiler automatically generates an entirely new class whenever you have a collection with a parameterized type.
C# added this nice thing called generics that’s the best of both worlds. Like Java collections, there’s just one class for all types of objects; like C++ template collections, instances are tied to parameterized types. The improvement on Java is that you have type parameterization, so you can specify at compile time what kind of objects are going into (and thus coming out of) your collections. But you do this without generating new classes for each parameterized collection type—rather, the parameters are set *per instance*.
The Java guys thought this was a good idea too, so it has made an appearance in the 1.5/5.0 release of Java (code-named Tiger, a name no doubt picked in order to cause confusion with Mac OS X 10.4).
There are bunch more features that make life easier: autoboxing (automatic conversion of primitive types like int and double to object types like Integer and Double), automatically iterating for loops (for object : collection rather than the full iterator rigamarole), and some others.
That was a long rant not really relevant to the meat of this post. The point is, I like Java way, way more now than I did. I don’t mind that generics work a little hackishly at the compiler level, for reasons of backward-compatibility: since I’m writing all new JDK 1.5/5.0/whatever the hell they’re calling it now code, I don’t have to worry.
The Wonder of Eclipse
I had heard about this free thing called Eclipse that’s all the rage these days, so I downloaded it and tried it out. At first I was confused—too many things going on! But after working with it for about a day, getting to know its way of thinking, I really like it. I’m particularly loving its refactoring features. Say I decide a method should be named something else, or have parameters in a different order: I just right-click, choose something from the Refactor submenu, tell it what I want, and not only does the method get fixed up, but every call to the method anywhere in the project gets fixed as well. Sure beats a manual find/replace, even if you’re comfortable with regular expressions (which I am ashamed to say are not second nature to me yet). Syntax coloring, completion, etc., etc., all nice.
One thing that annoys me: you can’t pop subviews of the window out into separate windows. You can create a new full environment window and do things that way, but I’d prefer being able to just drag a view out of the main window and have it magically turn into a single-function mini-window that logically behaves as a child of the main window. I like the one-window approach in general, but I like to be able to break things out across multiple monitors when I need to.
The only other annoyance is that completion doesn’t know the names to parameters (it calls them arg0, arg1, etc.)—they should integrate it with Javadoc and not just the class bytecode so this is smarter.
JUnit
I have also been hearing the joys of unit testing trumpeted for many years, but, being lazy and never working on mission-critical code, I never got around to using that methodology myself. Well, I read up on JUnit today and put in unit tests for the ParameterMap class in EcoGillespie, and, what can I say, it’s wonderful. For a modest increase in programming time, testing time will be greatly reduced, and test coverage will be way better. Furthermore, it just makes you write better code to write the tests first: your brain is forced to concentrate on the edge cases, as well as the usability of your classes, from the very beginning. Wunderbar.
Oh, and it integrates beautifully with Eclipse. And JUnit 4, which is built into Eclipse 3.2 (in development, but so far quite stable), uses a new JDK 1.5 feature called annotations to make defining test cases even easier.
Now that I’ve tried unit testing, I shall never go back! I’ll definitely add OCUnit tests to LilyPad.