Today is finally the day when I migrate to Eclipse 3.1. It has been released for a few weeks, but I had to wait until the plug-ins that I use regularly were updated, specifically Subclipse. Some stream of consciousness thoughts on the process.
The distribution of Eclipse 3.1 is 105 megs. NetBeans 4.1 weighs in at 46 megs. IntelliJ IDEA is 53.3 megs. I’m not sure why Eclipse is larger than both of them put together.
The next step is downloading the latest and greatest MyEclipse Enterprise Workbench, which is now a whopping 107 megs in its own right. I originally started using this product so that I could easily run Tomcat via the Eclipse debugger and in order to have a decent editor for JSPs, but it has grown into this monstrous beast that includes database browsing, generation of entity-relationship diagrams, and 100 other features that I never use. I can see myself migrating to the Eclipse web tools once they’re released. I have a perhaps irrational suspicion that MyEclipse has grown so large that it’s making Eclipse slower overall.
Other than some small, temporary problems related to starting up Eclipse and pointing it to my workspace without all off the requisite plug-ins present, the upgrade generally went without incident. In fact, I started this entry thinking that I would write up some tips explaining on what you need to do to upgrade without ruining your life, but I didn’t run into any land mines in the process. That surprised me.
Now to mess around with the new features and figure out whether the promised performance improvements are actually noticeable.
July 26, 2005 at 5:30 pm
You might want to try http://lomboz.objectweb.org/overview.html – Lomboz, as its open source and smaller than MyEclipse. I find that the performance of 3.1 is way better than 3.0. But the really good stuff is the Java 5 support and the upgraded Online update mechanisms.
July 31, 2005 at 11:20 pm
Have you tried NetBeans 4.1? I’ve been using it for months, working on a Java Swing application that talks to a Tomcat 5.5.9-based servlet application. I’m able to debug both ends in NetBeans, the tomcat configuration/deployment support is phenominal, and I find the coding environment to be superb, definitely more productive for me than Eclipse.
Last week I installed the Subversion module into it, from the NetBeans site, and it’s working fine so far. I’m currently working on a project that uses Tapestry, which has better support in Eclipse than in NetBeans, so while I still have to use Tapestry, I’m using NetBeans for Java coding… everything about it just feels better for me.
July 31, 2005 at 11:21 pm
Whoops, I meant to say, “while I still have to use Eclipse”, not “while I still have to use Tapestry”. 🙂 Using Tapestry is far from being a hardship. 😉
August 1, 2005 at 9:55 am
I tried to give NetBeans a shot, but I really hate Swing GUIs. I keep hearing good things about it, though, so I may give it another shot.
August 1, 2005 at 11:59 am
Generally speaking, I’m with you on Swing GUIs, but NetBeans doesn’t feel much like a Swing app to me. Maybe it did to you?
Some features I love about NetBeans over Eclipse: editor tabs show the whole file name, the Navigator window/panel, extremely smart and user friendly CVS support (I’ve just started using svn with it so I can’t say as much about that yet), excellent graphical diff, Swing GUI building support, library/jar/src/javadoc management, the “Find Usages” feature, I can’t find anything like that in Eclipse, “Auto Comment” feature for doing the javadoc dirty-work (maybe Eclipse has this but I haven’t looked yet), and a much easier to use keybinding customization interface.
November 15, 2005 at 10:15 pm
Just a response to Jim Reopcke’s list of NetBeans features…
CVS support Eclipse seems to have at least as good CVS support as far as I have found, plus an incomparably useful “Synchronize” view for changes… you can review changes made by other developers before updating/merging them into your own workspace, and you can review individual changes you have made before checking in. Eclipse 3.1 also adds change sets to this view, so you can organise your changes with comments as you make them, so you don’t have the issue of trying to remember what a particular change was for when you check in at the end of a piece of work. An excellent case of making it easy for developers to use intelligent checkin comments (instead of sweeping “fixed bug” comments), which makes it more likely that they will.
Excellent graphical diff Personally, I find Eclipse’s side-by-side diff much more useful, since you can edit local files directly in the diff (and then immediately see the effects on the diff), or copy particular groups of changes into your local file. Very useful for merging, in particular.
library/jar/src/javadoc management Eclipse provides support for project-agnostic libraries, as well as associating source/javadoc with project jars, and exporting jar resources between dependent projects.
Find Usages Eclipse most certainly offers this feature, in the Search menu (or Ctrl+Shift+G for the default keyboard shortcut). Even more, Eclipse supports “Call Hierarchy”… literally, show me every way that this method can possibly be accessed from every open project, in an intuitive call-tree view.
Auto-comment While useful for creating javadoc stubs, Eclipse will create a javadoc stub for you automatically when you create a javadoc section at the start of a method (configurable). Auto-comment also can’t create useful comments, but the comments will pass code auditing tools, so you are risking lowering code quality through poor documentation.
Key-binding customisation Which is easier to use is mostly personal preference, but at least the Eclipse interface allows all shortcuts to be changed, and all actions can be performed through a menu as well as through the shortcut. NetBeans has a shortcut Alt+Shift+F for organising imports, but there is no menu item to perform the same function, and the shortcut is not visible in the customisation interface. Give me working over easy-to-use, any day of the week.
Not to bash NetBeans, I absolutely love the fact that it understands the difference between a testing dependency and a runtime dependency! I do wish there was a way to cancel a build in progress…
April 22, 2008 at 12:42 pm
Once again I am wasting time waiting for an Eclipse build right now that I know is wasted and I cannot cancel. How difficult is it to guarantee the build is not a selfish thread. It is obviously on a thread; the cancel operation can be invoked asynchronously – it just never does anything until the build is complete. And to top it off – I see very few other people commenting on this!! Maybe it is just time to go into the source.