Following on from my recent piece on ”10 things I hate about Mac”, I give you “10 things I hate about Eclipse” (ideas which will be reminiscent of this thread on www.eclipsezone.com) in no particular order:

• Not a proper Mac application

• Application directory files

• Scrapbook

• SWT and memory management

• PDE manifest files

• Launch configurations

• Non UTF-8 text encodings

• Bugs

• Lack of detail in documentation

• Update sites and features

---

1. It’s not a proper Mac application. A Mac app should be fired up by a single program; the Eclipse app is actually a call to the eclipse launcher, which in turn fires up the Eclipse program. This causes all sorts of issues (for example, running AWT and Eclipse is problematic because Eclipse refuses to listen to AWT events on the thread it should do) which mean that it is definitely not a well behaved program. Normally, with a Mac app, it should be possible to double-click it a second time and have it take you back to the open program; with Eclipse, it starts up a new application each time. It also means that some features – like dragging a file over the .app icon – aren’t available.

   The program layout is entirely non-Mac like either; because of the inflexible build process, there has to be a file called eclipse in the root directory (which is why you see that next to the Eclipse.app) Totally unnecessary on a Mac, but the Eclipse release team demand that it be present. They don’t even get the MacOSX SWT example right:

   Spot the difference
   Mac Java guidelines	SWT example
   The directory layout should look like this: YourApplicationName.app/ Contents/ MacOS/ Resources/ Java/ ... Copy your Java .jar or .class files into /Contents/Resources/Java/	SWTHello.app/Contents/Info.plist SWTHello.app/Contents/Resources/swthello.icns SWTHello.app/Contents/MacOS/swthello SWTHello.app/Contents/MacOS/SWTHello.class SWTHello.app/Contents/MacOS/swt/libswt-*.jnilib SWTHello.app/Contents/MacOS/swt/swt.jar

   Lastly, no other Mac universe in the known world (even before, when it was NeXTstep) ever, ever used a shell script in the .app launch file. It’s frankly embarrassing.

2. It turds files over the application install directory. This is completely contra to almost every operating system’s guidelines, who already have areas set aside for user-specific documents (e.g. ${user.home}). Even with recent builds, Eclipse still feels the need to generate a configuration directory that it uses to store a global pointer of the user-specific location that hosts the workspace. And although it can contain references to the @user.home, if one were to change that in the default install then all users would suddenly be moved to that different location. OK, so it doesn’t create one if it can’t have the rights to create files in that directory; so why does it feel the need to create one just because it can?

3. The scrapbook page is both brilliant and pants at the same time. It allows people to ‘try out’ code semi-interactively, so it’s great for testing methods and the like. However, it insists that you save the result to a file before you can run it. Why? I’m trying out code, not saving it for posterity.

   Granted, there may be times when I want to save it as a file in order to recreate testing work later, but most of the time I just want to experiment with something before copying it into a class. It’s just completely unnecessary to make me save it; after all, the file gets translated on-the-fly to a temporary class, so the temporary class will almost certainly be generated somewhere, right? Why can’t it use that instead?

   And what’s up with having to select text before you can run it? There’s five lines of text there. I want to run them all, dummy. And don’t get me started with the frigging error messages; when has a non-interactive compiler or interpreter ever (in any other language, any other IDE) decided to mix the error results in with your source code? It’s not like it’s impossible to show a dialog, or have a split screen, or even printing it to the console.

4. SWT and memory management. There’s an argument that if you encourage developers to work in a good way, then they’ll follow that later. dispose()ing of resources when you’ve finished with them (or using an appropriate resource manager) is encouraging things the good way. However, if you don’t dispose them, they’ll just eat up more system resources until you finally run out of memory.

   It would seem sensible then, to write a finalizer that ensures should a SWT widget be garbage collected before the system resources are disposed, that the dispose() method is called automatically. Apparently not. If you’ve been smoking what Joshua Bloch is smoking (he who doesn’t know how to implement an equals method