Odi's astoundingly incomplete notes
New entries | CodeEclipse annoyances
In a recent blog post Tapestry developer Howard Ship lists some points that annoy him personally in Eclipse because they hinder his productivity. I must say, that none of his points ever was a problem for me. Maybe except of the key binding thing.
I use Eclipse daily and I am mostly very happy with it. It does its job very well. And the CVS integration is very well done. What bugs me most every day are the following things however.
Full rebuilds
I have all projects set to "Build automatically". I think this is the only setting that makes sense. Otherwise you end up with heaps of bogus warnings/errors and you must manually build before running Unit tests. Then I have many large projects open in a single workspace. Dependencies exist between many of these projects. Some of the projects have dozens of libraries imported. Now it happens sometimes that Eclipse wants to perform a full build of all projects, which can easily take up to 20 minutes to complete. During this time the (Windows) machine becomes virtually unusable because of excess disk I/O. I would very much prefer if in doubt Eclipse would ask me if it should perform a full build or if I would take the risk to have stale class files. A full build is always performed after a crash (or kill). And I have to kill Eclipse about once a week, because it hangs itself in an endless loop.
Hot code replacement and different branches
This is a bug. And it's very annyoing when you work with multiple branches of a project. Hot code replacement is a really cool feature of the Java VM. It allows to modify code on the fly during a debuging session without restarting. However, Eclipse blindly uploads any class that you modify into the VM completely ignoring the project that the class belongs to. If you work with multiple branches there will be a lot of matching package/class names. So any unware save will upload a completely different version of the class and destroy the program running the debuged VM.
Pseudo-asynchronous tasks
It's a nice feature that you can put almost all long running tasks in the background. But for many of them this is a pseudo-feature. Because as soon as you want to save a modified file, a dependency dialog pops up, saying that it is waiting for the background task to complete. Clearly there are too many dependencies defined. Saving a file of a non-Java project with no dependencies should not wait for compilation of totally unrelated projects to complete.
Hangs
Sometimes Eclipse would suddenly madly access the disk when I roll over the menu bar, or try to access the search menu. Then after accessing the disk it would hang for several seconds. The whole thing leads to about 30 seconds of unresponsiveness of the whole UI. It seems like
Screen clutter
Sometimes the menu has already opened during a hang. When I try to do something else during that time, like read my email, the opened menu clutters the screen of other applications. It's completely in the foreground and you can't make it go away.
Plugin-Dependencies prevent customization
Eclipse has this nice plug-in architecture. But then also Eclipse comes in pre-configured packages like Eclipse for J2EE developers that already contains many essential plugins. Now some of these plugins I never use and would like to uninstall them. Like that dreadful Mylin. Or JPA support (Dali). And I can't because they all are a dependency of "Eclipse IDE for Java EE Developers". That's just plain stupid. Also the plugin manager changes a lot between every release. A clear sign that this beast has a lot of problems.
Context menu bloat
Plugins can extend the context menu. To some degree you can configure that in the perspective. But some plugins seem to just add to the context menu anyway. So especially the project context menu contains so much bloat it's ridiculous:
I use Eclipse daily and I am mostly very happy with it. It does its job very well. And the CVS integration is very well done. What bugs me most every day are the following things however.
Full rebuilds
I have all projects set to "Build automatically". I think this is the only setting that makes sense. Otherwise you end up with heaps of bogus warnings/errors and you must manually build before running Unit tests. Then I have many large projects open in a single workspace. Dependencies exist between many of these projects. Some of the projects have dozens of libraries imported. Now it happens sometimes that Eclipse wants to perform a full build of all projects, which can easily take up to 20 minutes to complete. During this time the (Windows) machine becomes virtually unusable because of excess disk I/O. I would very much prefer if in doubt Eclipse would ask me if it should perform a full build or if I would take the risk to have stale class files. A full build is always performed after a crash (or kill). And I have to kill Eclipse about once a week, because it hangs itself in an endless loop.
Hot code replacement and different branches
This is a bug. And it's very annyoing when you work with multiple branches of a project. Hot code replacement is a really cool feature of the Java VM. It allows to modify code on the fly during a debuging session without restarting. However, Eclipse blindly uploads any class that you modify into the VM completely ignoring the project that the class belongs to. If you work with multiple branches there will be a lot of matching package/class names. So any unware save will upload a completely different version of the class and destroy the program running the debuged VM.
Pseudo-asynchronous tasks
It's a nice feature that you can put almost all long running tasks in the background. But for many of them this is a pseudo-feature. Because as soon as you want to save a modified file, a dependency dialog pops up, saying that it is waiting for the background task to complete. Clearly there are too many dependencies defined. Saving a file of a non-Java project with no dependencies should not wait for compilation of totally unrelated projects to complete.
Hangs
Sometimes Eclipse would suddenly madly access the disk when I roll over the menu bar, or try to access the search menu. Then after accessing the disk it would hang for several seconds. The whole thing leads to about 30 seconds of unresponsiveness of the whole UI. It seems like
Screen clutter
Sometimes the menu has already opened during a hang. When I try to do something else during that time, like read my email, the opened menu clutters the screen of other applications. It's completely in the foreground and you can't make it go away.
Plugin-Dependencies prevent customization
Eclipse has this nice plug-in architecture. But then also Eclipse comes in pre-configured packages like Eclipse for J2EE developers that already contains many essential plugins. Now some of these plugins I never use and would like to uninstall them. Like that dreadful Mylin. Or JPA support (Dali). And I can't because they all are a dependency of "Eclipse IDE for Java EE Developers". That's just plain stupid. Also the plugin manager changes a lot between every release. A clear sign that this beast has a lot of problems.
Context menu bloat
Plugins can extend the context menu. To some degree you can configure that in the perspective. But some plugins seem to just add to the context menu anyway. So especially the project context menu contains so much bloat it's ridiculous:
- Why would I "Profile as", "Debug as", "Run as" a whole non-Java project?
- What exactly is "show in remote systems view" supposed to do? Apparently nothing happens when you select it.
- This "Instrumentation source" bullshit. I once accidentially clicked it and it started messing with my code! Luckily I had just comitted my changes to CVS, so nothing was lost.
- All sorts of actions to add project natures: "Add Javascript support", "Convert to JPA project", "Convert to Plug-in project" etc. Nobody does that all the time. It has no business in a context menu.
-the eclipse context menus suck, they almost push an IBM world view "write a web service endpoint", "sign a contract with IBM global services to fix this method", etc.
-SteveL
When you download and install a 'product' , such as IDE for Java developers, it's expected that you won't remove the base components.
Robert Munteanu