Jeroen’s weblog

Recently I’ve been doing a lot of Java programming. Not by choice but because the project I’m working on is supposed to be cross-platform. The funny thing is, when I started out I kind of dreaded losing the new yield-construct in C# along with all the other things I like better about C# (no rules about file/directory names/layout, unsigned types, explicit interface implementation) but was actually looking forward to dive into Eclipse, the IDE of choice of just about every Java developer I know. A couple months later, it seems I was wrong both about Java and Eclipse.

First of all, Java is actually quite a usable tool. My current project has some problems with it, mostly because it involves a lot of low-level parsing and the lack of unsigned types in Java makes this a headache. Another thing that I just can’t get used to is that terrible scheme where every class must be in its own file with the same name and every file needs to be in a directory corresponding to the entire package tree. There are simply no real advantages to it. But that’s, as it turns out, not really a problem: when you know about the differences between Java and C# they’re way more similar than different.

Eclipse is a different story. I was using it a couple of weeks before Visual Studio 2005 shipped and was amazed that it actually already supported a wide range of refactorings, along with good intellisense. The debugger especially amazed me, as it’s quite similar to the Visual Studio debugger, with the added bonus that I could now step into the class libraries thanks to the sources included with the JDK! But then I seriously started using it for development and frustration took over.

For instance, if you define an ANT-task to be automatically executed after a build, the task will simply clear the output window and use it for output from the ANT-task. Even if the window was used two seconds ago to display update information from source control. Also, if you have projects that you want to be able to check out and use independently, you might be tempted to have them depend on each other’s output (a JAR file for instance). This simply doesn’t work. It usually takes me 5-10 minutes to get one project to do a rebuild (usually opening a file, adding a space to it so the compiler understands that there’s a change) and for the other to recognize the fact that one of its dependencies has changed. For this last one I don’t even have a workaround, you just have to keep pressing F5 (refresh) on all involved directories in Eclipse and hope that at some point it decides to update its dependencies. I usually end up removing the reference and adding it again.

And then there’s workspaces. These are basically solution files only they’re stored in a directory instead of a single file (I have no idea why anyone would want to do it this way) but that’s not all: they’re machine-specific. So you can’t check them into sourcecontrol and have someone else automatically get the same list of projects loaded into Eclipse by checking it out. I ended up lumping everything into a single Eclipse project. Not because that’s a good way to do it, but because it’s the only workable setup.