I added this image of Eclipse 3.3M6 running on Windows Vista to the Eclipse Screenshots page. In the process, I’ve started to revamp the page. I’m thinking it’s a little too cluttered: less is more, right?

Right. The image…

It looks pretty good. It looks as Vista as everything else on my desktop. To be honest, I find the whole see-through trim thing around the windows pretty cool, but after about 15 seconds, not all that interesting. Still, Eclipse looks right at home on Vista.

The SWT team has been doing some great work getting SWT ready for Vista. They’re building a whole new implementation of SWT on Windows Presentation Foundation (WPF). You can download native WPF versions of the latest and greatest builds of Eclipse 3.3 right now. The implementation is almost complete. One thing that I’ve noticed is missing is drag and drop support. This is coming, it just hasn’t been implemented yet.

As far as I am aware, Eclipse 3.3 should end up being one of the first native WPF applications available when it is released in June as part of the Europa release train. By extension, that means that pretty much every (let’s say 95%) of the Eclipse RCP applications out there are also among that first wave of native WPF applications.

It’s been a great month for me hardware/platform-wise. In addition to this new 64-bit AMD box running Windows Vista, I’ve scavenged another slightly used box and have installed Debian Linux. So far, I’m pretty impressed with the user experience; it goes a long way toward making Linux really easy to use. Unfortunately, I apparently still need to remember the syntax for that darned mount command. Now how is it that I specify the user id again…

I actually had somebody say this to me:

“I can’t use a distro of Eclipse. My boss demands that we only use ‘official’ software from the eclipse.org site. By the way, does it work on Debian Linux?”

The blogging recently about including Subversion support in the Eclipse SDK made me think of this comment (I’m paraphrasing a bit) from the past.

Why does software have to come from eclipse.org? Nobody uses Linux; they use RedHat, Debian, Ubuntu, Gentoo, or whatever. You don’t use Linux, you use Linux distros.

So why not explore distros? There are many. Check out the Eclipse Distros page for some of the ones we know about. Heck, you can even get a distro with Subversion support pre-installed.

If you don’t want to deal with plug-ins yourself, try a distro. Seriously. Do it now. You can still add plug-ins later if you want.

I’ve been pretty quiet lately for a couple of reasons. I’ve been spending a great deal of time over the last two weeks preparing for Eclipse Forum Europe (EFE) this week. I arrived in Germany a little earlier today; with my presentations pretty much good-to-go and all domestic responsibilities deferred for a week, I finally have a little time to return to the surface.

I’m delivering two talks at EFE, both on Wednesday. The first, “Test First Development Using Eclipse” is a completely new talk that discusses (oddly enough) test first development using JUnit in Eclipse. I start off with some pretty simple Java examples (similar to what I do in a screencam I recorded last year), move quickly into plug-in testing, and then dive into some J2EE testing. All with a test first methodology (that is, tests are written before the code being tested).

The second talk is titled “Anatomy an Eclipse RCP Application“. This talk is an evolution of a webinar—with the same title—that I delivered a few months ago. For the webinar, I had intended to do live code walkthroughs, but was halted by technology limitations. I’m going with the original plan this time through. I’m trying something new with this talk: I’m defining tasks in Mylar that contain relevant code artifacts for each aspect of the walkthrough. Essentially, for each concept I want to talk about, I only have to activate the relevant task and only the bits of code that implement that concept will be visible in the package explorer. Mylar is so very cool.

I’m hoping to try something else that’s a little new (at least for me). I’m going to record my talks as screen cam demos. If it works out, I’ll post the demos on Eclipse Live.

I’m also hosting a Eclipse Code Camp on Wednesday evening, and will be representing (at least informally) Eclipse at the W-JAX Ballroom.

I’ll be wandering around the conference and exhibit floor on Tuesday and Wednesday. Please feel free to stop me to discuss any aspects of Eclipse that interest you. Also, if you’d like to participate in a podcast with me, please let me know (either by comments to this blog entry or via email: wayne{at}eclipse{dot}org).

correction: Thanks Wassim for noticing that I had previously specified my e-mail address incorrectly. Yikes!

Don’t forget to vote for your favourite Eclipse-based technologies in the latest run of the JDJ Readers’ Choice Awards.

Ian announced the availability of Eclipse Live last week. The first big event on Eclipse Live is a webinar by the Device Software Development Platform (DSDP) Project titled “The DSDP Target Management Project” on April 12, 2007. Here’s the abstract:

“The Target Management project provides a framework, widgets, and tools to manage remote systems under a single, consistent user interface. Ready-to-use tools for remote file and shell access, as well as launching remote CDT applications can be used from embedded to mainframe operations. APIs allow vendors to plug in their own connection schemes and system or subsystem types. This webinar will give a brief overview of the Target Management project’s scope, goals, current state, and future directions. We will give an online demo, explain important concepts, and show how to extend the framework. Special emphasis will be given to components like the new Terminal framework and other upcoming enhancements.”

Register today!

I’m up to reason seven in the “Ten Reasons to Use Eclipse” posted by Renaud Waldura (my discussion of the previous six reasons can be found here: 1, 2, 3, 4, 5, and 6). I have to admit that this is one of my favourite reasons.

One aspect of Eclipse I dearly love is the utter lack of a “Build” or “Compile” button. Isn’t it paradoxical, an IDE that doesn’t let you build? IDEs started precisely as GUI wrappers around a compiler and a make tool, how can the “Build” feature be absent?

Here’s the key: Eclipse always builds for you. Every time you save a file, run a program or a tool, or any other action that accesses resources contained in the project, Eclipse compiles. This essentially means your code is always compiled. (Note that a “Rebuild” menu option is still present for those rare cases that require a manual build.)

I find this to have a profound impact on my programming work. For the first time I’m working in an environment where the natural state of code is compiled. Text, source code, used to be the primary form of a computer program. In Eclipse, source code has almost become a transient state, used only as input to the compiler. As soon as possible, and in fact, almost continuously, code is compiled to its binary form, with all the benefits of compilation (type checking, static analysis, etc.). Eclipse also builds incrementally, thus ensuring that most build operations are completed within seconds.

I couldn’t agree more. Incremental compilation rocks. However, it does tend to catch people off guard. On a fairly regular basis, we get questions about compiling Java in Eclipse (generally on the newcomer newsgroup, or on EclipseZone). Most folks assume that there is a big “Build” or “Compile” button hidden somewhere but can’t find it. It’s initially hard for some folks to get their brain around the fact that compilation of Java code just happens (usually Eric or Ed will set them straight).

Incremental compliation ensures that your application code is always ready to run. As Renaud points out, Eclipse keeps track of the dependencies amongst all the files and rebuilds only those components that need to be rebuilt. Compilation happens in the background, so unless you’re paying attention, you’ll likely not even know it’s happening.

As an aside, something that a lot of people don’t know about the Eclipse Java compiler is that it was designed to be decoupled from the Eclipse platform. The JDT can be used separate from the Eclipse platform; even from the command-line. If you’re using Apache Tomcat to host Java ServerPages (JSPs), then you’re using the JDT. When you’re using the JDT batch compiler, you don’t get the fancy incremental compilation, but you do get a darned fast, top-quality Java compiler that you can easily make a part of your Ant build scripts.

I love the Java compiler in Eclipse. Of course the notion of incremental compilation isn’t anything new. We’ve had incremental compilers for years. I am duty bound to point out that incremental compilation was a fundamental part of Smalltalk. VisualAge for Java also employed incremental compilation. It is natural, then, that the JDT developers would make it a fundamental part of their implementation.

Them JDT guys are some smart.