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.
