Execute them! Bogus.

Many of the Eclipse projects are presented as Platforms, but to make a successful platform you have to balance at least two factors in much the same way as an economist: the value provided and cost incurred. The value added is simply the feature set--is there something of use in there? The other factor, cost, is made up in part by the requirements. For Eclipse plug-ins this is often only thought of as which plug-ins it requires to run, but there's also the Execution Environment to consider.

One of the great things about the PDE is that when you specify an Execution Environment for plug-in projects and have matching Installed JREs within the preferences, it will automatically target your plug-in projects to use the right JRE. No more warnings about generics in a project that hasn't adopted Java5 syntax or about not supporting them in the targeted JRE. This even lets you build plug-ins specific to each environment if needed, allowing for multiple implementations of the same functions, or more commonly the graceful deactivation of certain features when running in older environments.

The larger ramification is that the Execution Environment is now every bit as critical to think about as the plug-in and version dependencies. If you are developing a plug-in that specifies an Execution Environment of J2SE-1.4 but has a dependency on a plug-in specifying an Execution Environment of J2SE-1.5, your plug-in now implicitly has an Execution Environment of J2SE-1.5 as well. Conversely, the Execution Environment you specify on your plug-in has a direct effect on how readily it can be used by someone else, and that affects the cost of adopting your platform. It's little surprise that much of the Eclipse Platform as we know it requires J2SE-1.4 or less. So keep in mind the Execution Environment you choose for your plug-ins--some day you might find it running in the most unexpected of places.

The Bug Day Cometh

For those not in the know, a Bug Day is a day when we, the developers, pause for a moment and take a fresh look at our bug backlog. For the larger community it's a chance to help triage bugs by sorting out which ones are still problems, or even just identifying the ones that need more information. After all, unless there's enough information in the bug to help developers reproduce what's broken, it can't be fixed. For anyone who wants to get into the development of an Eclipse project, it's also a great time to submit a patch and get feedback from the committers within the bug itself or through other avenues such as IRC. However you participate, it's a day to remember that we can't make our projects their best without the help of the community, and for the community to help us to scratch whatever has been itching at them.

As of right now, two committers have signed up to be contacts for the Web Tools Platform project, but I wouldn't rule out there being more committers before the day itself arrives, or more projects at that. As has been pointed out elsewhere, the first day is largely an experiment.

Join us, won't you?

Keyword filtering, or I hear the '70s are making a comeback!

It's a strange thing thinking about the evolution of interfaces for microcomputers. We started out with command lines, and then went to smarter command lines, and then swapped those out for GUIs. Browsing for the right command using windows, icons, and menus was supposed to be easier than trying to recall arcane command names and options, and yet here we are going back the other way. The rise of feature-laden applications and operating systems has led us back to relying on text, again, as Google Desktop finds itself preinstalled on my newest work machine and both Apple and Microsoft tout the built-in search facilities of their latest Operating System offerings.

And how is Eclipse related to this? Adopters probably realized early on that adding each preference page into their products had a cost: it made it harder for a user to find the important one. Eclipse 3.2 brought us the org.eclipse.ui.dialogs.FilteredTree control and used it in the Preferences and project Properties dialogs, helping to alleviate some of that problem. It searches the names of the individual pages for matches against what the user types into a text field, automatically benefiting from string externalization of the page titles. But did you know you it can go deeper? I present the org.eclipse.ui.keywords extension point. It allows you to define a list of keywords which can then be used for additional hits in the filter field, allowing a search on formatting to reveal WTP's formatting-related preference pages:

Not bad for an extra couple of words.

On the eve of Europa

Looking back on the eve of Europa's release, it's hard to quantify just how much has happened since Callisto was unleashed upon the world. No doubt there will be many metrics reported within the next few days, builds done, plug-ins created, disk footprint altered, etc., but one number caught my eye: 45585. Well, 45586, now, and still counting. Bug 149295 has the strange honor of being opened at 9AM on June 30th, 2006, the minute that Callisto was meant to be released. That's 149,294 entries in the system going from October 10, 2001 to the middle of 2006. And where do we stand now? The most recent bug I've seen opened is 194881, meaning that 45,486 entries have been added in the last year alone, and we're still going.

Have you thanked your webmasters today?

There, I Said It.

Comforted by the fact that most attendees have likely already signed up and chosen their tutorials, I'm boldy going to suggest you meet the SSE team at EclipseCon 2007 and attend our short tutorial on extending our editors. Editors may not be the glamourous part of any IDE, but it's a crucial one if you write code at all, and if your source editor messes anything up, users tend to be extremely vocal about it.

It's no mean feat trying to support 6 source languages competently while chasing the feature set of the standard-setting Eclipse Java Development Tools. Of course there's also the task of reacting to those rare changes that have them catching up to, and sometimes inadvertently breaking us, while still providing just enough framework for other folks to do some truly interesting things that we'd never focused on. In any case, our team doesn't look to be getting bored any time soon.

Here's hoping we can continue the tradition of our team not dying in a fiery dramatic crash like we almost did last year.