Dr. Margarent-Anne (Peggy) Storey is a professor of Computer Science at the University of Victoria. In this podcast, Peggy discusses GILD, the IDE based on Eclipse developed at the University of Victoria to introduce new students to software development. She also discusses the Zest project and introduces TagSEA, a “a robust, extendable framework with exemplary tools used for tagging and waypointing source code, resources, or whatever you would like within Eclipse.”

You can find the podcast here. You can get your iTunes fix here. Or hook up the RSS feed to your favourite reader here.

I’m up to #6 in the “Ten Reasons to Use Eclipse” posted by Renaud Waldura sometime in late 2002/early 2003. Since I’m crossing the halfway mark, I thought I mightlay out the previous reaons five for your review.

1. Eclipse is Free
2. Eclipse is a Platform
3. Eclipse Has Momentum
4. Eclipse is Easy To Extend
5. The Eclipse Workbench: Views, Editors and Perspectives

Here’s reason #6:

Maybe this one is a pet peeve of mine, but I simply cannot stand waiting for menus to pop-up. Typical developer machines are less than a year old, and have more than enough horsepower to run any desktop application. How is it possible that a Java app still feels like a Java app, to the point that any developer can always tell an application is written in Java by its slow execution speed and quirky fonts?

Maybe an answer to this problem is SWT, the Standard Widget Toolkit developed by the Eclipse team as a replacement for AWT/Swing. In addition to making the application look like any other native application, which is a gread-breaking improvement in itself, SWT seems to greatly improve the performance of GUI display. And maybe, just maybe, the Eclipse developers care more about performance than others. The Eclipse development process consistently lists explicit performance milestones that must be reached before the product ships.

I have a problem with this one: the title is wrong. If you’re going to state that something is faster, you really need to state the what that it’s faster than. That said, it’s still true that Eclipse is a decent performer. And it’s true that there are performance targets that are consistently met. There have been some problems with Eclipse performance over the past few years, but these have often been caused by adding very large numbers of plug-ins on top of Eclipse and are easily mitigated by changing the way that the underlying Java virtual machine manages memory.

It may be true that SWT is responsible for the zippy performance. This was certainly true in the earlier days, but with improvements to competing technologies, any performance improvement bought through the use of SWT is difficult to discuss without igniting a savage battle.

Even putting aside any arguments involving SWT, I still think that Eclipse is faster. Out of the box Eclipse makes me productive. I don’t have enough experience with competing products to say whether or not Eclipse makes me faster than those competing products, so I won’t. To keep things simple, let’s say that out of the box Eclipse makes me about as productive as an equally competent developer expertly working with one of those competive products. I have a great deal of confidence, however, that Eclipse with Mylar makes me at least an order of magnitude more productive with Eclipse than I was before I started using it. By extension I’m at least an order of magnitude more productive than that increasingly hypothetical equally competent developer expertly working with a competitive product.

Mylar truly is proof that innovation is alive and well at Eclipse. A lot has already been written about Mylar, so I won’t rehash that here (at least not too much). The simplest way to put it is that Mylar makes it really easy to find things that I care about while I’m working. Since I spend a great deal of my time finding stuff, Mylar makes me more productive. And I’m not joking or exaggerating about the order of magnitude.

The notion of faster can be further generalized. Eclipse allows you to bring all of your tools together onto a common platform. You can get productive fast by applying knowledge gained in the use of one set of tools to another. With Eclipse BIRT, you can build professional quality reports; while it’s true that you’ll have to put some effort into learning how to actually build the report, the way that you manage the resulting files, save and share them with your team is already very familiar if you’ve been using Eclipse for other tasks. Similarly, I can manage and manipulate my databases using the Eclipse Data Tools right from the comfort of the environment that I’m already familiar with. I can also build my C/C++, Ruby, Ajax, or whatever applications using that same comfortable environment. And that’s just the tip of the iceberg; for some, Eclipse is already the desktop.

A slightly different take on the “Eclipse is Faster” theme leads me to Eclipse Rich Client Platform (RCP). I can churn out a very functional application very quickly using RCP. In that regard Eclipse is way faster than more traditional methods of developing and delivering desktop applications. Eclipse on the server with Equinox/OSGi has a lot of potential to make the development time-to-market and runtime performance stories for server-side applications a lot quicker as well.

What about great stuff like EMF, ECF, Higgins, RAP, and so on? This post is getting far to long to talk about all the ways in which Eclipse makes it fast and easy to develop applications.

So, is Eclipse still faster? I think so, but not in ways that Renaud was originally thinking.

In this podcast recorded at EclipseCon 2007, Mik Kersten discusses how a bout with repetitive strain injury (RSI) motivated the creation of Mylar. He also provides some insight into how Mylar was/is built and integration of Mylar with Java (JDT) and other languages.

For those of you who have been living in a cave over the past six months or so, Mylar is something that will change your life.

You can find the podcast here. You can get your iTunes fix here. Or hook up the RSS feed to your favourite reader here.

I love how I continue to discover new things in Eclipse.

A few days ago, I stumbled upon “Show Logical Structure” . This is a feature that has been around since the 3.1 days (I believe it was introduced with 3.1M4). It turns the “Variables” view (normally part of the “Debugging” persective) from this:

Into this:

When I’m debugging something, I normally don’t care too much about the internal representation of an ArrayList. With “Show Logical Structure” turned on, the list manifests as an array which is far more useful. Other structures are handled by the feature, and it’s possible to create your own logical structure mappings for other types.

We need help with the Google Summer of Code.

Desperately.

We have almost 100 proposals submitted and we’re desperately short on mentors. If you’re interested in being a Google Summer of Code Eclipse mentor, please let me know (wayne at eclipse dot org).

What does being a mentor require? It requires some of your time. Last year, our mentors spent an average of about four hours each week on each student they mentored (Caffeine Chris mentored about half a dozen of the projects last year). Students are expected to provide their own workstations and work locations. Last year some of the mentors interacted with their students over the phone, Skype, IM, and IRC. I think a few of them actually made some space for their students (but this isn’t necessary).

With reasonable investment, you get reasonable return. In many cases, the code that resulted from SoC projects ended up in Eclipse projects. At least two students from last year’s SoC became Eclipse committers. Good stuff comes out of this, but you have to invest a little time. You’ll have to decide if it’s worth it.

Signing up as a mentor doesn’t commit you to mentoring a project. Once you’re in, you get to review the proposals; if there’s something you like, you can offer yourself as a mentor. If you don’t find any of the projects interesting, you can at least help us wade through the proposals and identify the good ones. Then Google gets to decide how many of our projects it wants to fund and you may find yourself with a eager well-feed protegé.

We have particular need for mentors familiar with CDT; there are a handful of CDT proposals that I can’t make heads or tails of. They sound good, but I can’t tell how useful they are. There’s a couple that will be of interest to the platform team, Maya folks, and much, much, more.

Anyway, if any of this sounds useful to you, drop me a line. Philippe Ombredanne is the real brains of this operation so I’ll forward your interest on to him. Please make sure that you tell me a little bit about yourself; it’s important that we know who the mentors are.

I just posted a new podcast. In this podcast, Benjamin Pasero, technical lead on the RSSOwl 1.0 project and self-described “significant contributor” to the RSSOwl 2.0 project discusses—among other things—the decision to adopt Eclipse Rich Client Platform (RCP) as a basis for the new version.

This was recorded at the Open Source Pavilion at EclipseCon 2007.

You can find the podcast on the Eclipse Resources page, or click here for a direct link. The Eclipse Resources page contains numerous links to include podcasts in your favourite reader (just scroll down, it’s on the right side).

I spoke with Bob Goodman, Ajax Toolkit Framework (ATF) Project Lead, at EclipseCon about the ATF project. During this conversation, Bob told me about all the great features alredy available in ATF and spent some time looking into the future.

You can find the podcast here, or pick up the feed here.

The student application deadline is approaching quickly. March 26 is only days away.

Thus far, we’ve received 27 applications for Summer of Code projects. Frankly, there aren’t very many good ones. This is good news for students because it means that there will a really good chance that you’ll be accepted if you put a little effort into your application. Make sure that you give us enough information: we need to know what it is that you’re planning to accomplish with your time (and Google’s money) this summer. This isn’t the time for vague descriptions. Be specific. Also, be realistic. What do you honestly think that you can accomplish with the time allowed?

Time is running short. Get your project proposals in. Do it now. That term paper can wait. The time you waste studying for your exams now is time that you could be spending putting together a rock-solid proposal.

Information about Eclipse participation in Google’s Summer of Code can be found here. We’ve even thrown together some project ideas here. You don’t have to take our ideas. Make something up. Surprise us. Then go study for that exam.

It’s time to continue with my ongoing series based on a list of “Ten Reasons to Use Eclipse” crafted in the Eclipse 2.0 timeframe.

Before we get to reason #5, I have to admit that I’ve been carefully referring to the “Eclipse 2.0 timeframe” because I couldn’t remember precisely when that was. Today I decided to visit the Eclipse archive site and sort it out. Eclipse 2.02 (the last “2.0″ release”) occured on November 7, 2002. That’s almost five years ago. And what an amazing five years it has been.

Reason number five addresses the Eclipse workbench:

#5 - The Eclipse Workbench: Views, Editors and Perspectives

Eclipse implements a strong UI metaphor, the result of years of research and development in IDE technology: the workbench. Simply defined, the workbench is a space where work is performed using a range of tools. In Eclipse-speak tools are called views and editors, and a given layout of tools is known as a perspective. Eclipse Views

Java Perspective with Console View

There are many views and editors; each is dedicated to a specific functionality. E.g. the Java editor highlights Java syntax; the Hierarchy view shows the class inheritance hierarchy; the Console view displays System.out messages. Each view is contained in its own window; a view can either be “pinned” to the workbench, where it becomes part of the current perspective, or it can be “floating”, and iconified for later access. A perspective encompasses the tools and resources required to solve the current task. It selectively displays views and the resources they show. A perspective can be customized by moving views around, and by selecting which views are always open (pinned), or accessible through the icon toolbar.

Again Eclipse mirrors the reality of software development: as I move from analysis/design to implementation, then to testing and debugging, Eclipse allows me to use the most appropriate toolset simply by switching perspectives. Default perspectives exist and embody the most common tasks. E.g. the Debug perspective opens all debugging views, used to trace code, set variables and breakpoints; the Java Browsing perspective shows the Hierarchy view, the package, class and method views, as well as the Java editors.

This simple yet powerful “workbench” metaphor is what makes Eclipse such a superior environment, easy and enjoyable to work with. The IDE has many features, conveniently accessible when needed, yet easily hidden when not. E.g. I write my code in the Java browsing perspective, which displays the class/method views. Running the JUnit tests pops open the JUnit view, which I file away (iconify) as soon as all tests have passed. To write my Ant build file, I switch to the Resource perspective where the entire project tree is shown. At all times the IDE has provided me with the tools I need for the task at hand, and only those. I decide what set of tools I’m going to need, and how they are presented to me.

(If you need to catch up, see reasons 1, 2, 3, and 4).

All this is still true. And it just keeps getting better. The Java editor is now way smarter. Editors can be tiled. Multiple editors can be opened on the same file. Navigation within the environment is far easier (ctrl-e). It’s dangerous to talk about what’s improved because the list is very, very long and it’s easy to forget to include great features. The workbench used to be great. Now it’s better. And it keeps getting better.

Perspectives are very useful at bringing only those tools that you actually need to bear on the problem you’re trying to solve at the time. Perspectives can, of course, be modified so that you can tune your environment as you’d like. Don’t like switching to a different perspective when you start debugging? Fine, just open the debug views that you need into your Java perspective.

I guess that what’s most clearly changed is that there’s more. Now, you can switch to a “Reporting” perspective to build, edit, and run reports using BIRT. Or you can use the handy J2EE perspective to focus tools for building J2EE applications on your problem (thanks to the Web Tools project).

More isn’t necessarily better. Sometimes, less really is more. Enter Mylar. Mylar has made a big splash by—in a way—having a very small impact. The editors, views, and perspectives that we all know and love have been made better by Mylar; all without changing very much or adding gobs of new stuff to learn (maybe a handful of menu entries and a couple of views are added to the UI). Mylar sits back and watches you. It automatically tucks away the stuff that you don’t care about, and brings to the foreground the things that you do care about.

Bottom line: Everything that was great about the workbench before is now better; innovation is alive and well at Eclipse.

Check out this screenshot of SWT running the Windows Vista calendar control.

I like what they’ve done; clearly Microsoft has done their homework. The best part is that with SWT, you can use this widget today.