The next milestone of Eclipse 3.0 is out: M8. There are always plenty of new features to talk about, but here are a few I'll comment on:

When Eclipse starts for the first time it asks you where your workspace is or should go. Windows users don't have to set their workspace at the command line and Mac users don't have to dig into configuration files. Very nice.

The SWT people have improved the SWT Table to allow for virtual tables. As I understand it, the model data will be with the table but TableItem objects (rows) will only be created as they are needed (when the row is displayed in the UI), which is great for large tables. Seems like it will be done by M9 and I'm anxious to see if it will improve performance for tables in AudioMan, which start getting slow to load after a few hundred rows.

The new look and feel of Eclipse has been toned down a bit. Feedback on new M7 look and feel was very mixed -- people either loved it, hated it or took a while to get used to it. I'm still not used to it but I haven't used it that much yet. It didn't help that Ant support in M7 was broken and I had to go back to M6. If you think the Windows look and feel is weird, you should see it on the Mac! I'll give them a break though -- it's a work in progress. At least they are listening to their users' feedback and have responded in less than six weeks: that's the most important thing. This is why regular incremental releases and iterative development is a good thing: your customers get what they want, and quickly.

When I try to use the Ant plugin in Eclipse 3.0 M8 it is still broken out of the box. If the Ant plugin comes with the junit JAR file why can't it find the junit task without any help? Seems like basic seamless integration to me but they are taking the stance that developers will manually add junit.jar if they require it. The Ant plugin could watch for optional tasks in the build.xml file and pull the JAR files that it already has in automatically as they are required. That would be a lot more friendly. I understand the stance that they can't pull all of them in by default because it would be a waste but a little code intelligence might solve this problem.

Update 7:12 PM After reading more comments on bugs, it seems that while many people don't like the new look and feel the Eclipse UI team may be resisting either 1) a change back to the old native look and feel or 2) supporting both look and feels because either option would be a lot of work and/or complicate Eclipse. They are currently gauging support for either option with Bugzilla votes.

Probably the worst part about this new look and feel is that there was no warning of it (at least not outside of their bug repository) or solicitation of comments. If they had proposed the new look and feel before committing the resources to implementing it they may not have had to backtrack like may do now. The concerns are especially true for people already invested in the Rich Client Platform which uses the new look and feel. The decision to develop the new look and feel without input from everyone was risky -- I wouldn't blame (not that they are) the users (whether they be Eclipse developers, users of SWT, or users of RCP) for giving them something they didn't want.

Update Wed 5:55 AM: the Eclipse team responded to feedback from changes in M7 with these comments.