Extending Eclipse's Java Development Tools - How easy it is (!?!)

[Dan Kehn]

That's it, today's the last day of "authors' week" at the JavaRanch. The JDG2E posse would like to thank y'all for inviting us to sit a spell. Soon the Sheriff will announce who's won them free books... there's still time, get a move on!
Before we ride off into the fading sunset, Dastardly Dan would like to give y'all a little gift. He's not always dastardly, ya know.
This is a preview of an article that will appear on developerWorks this coming Tuesday. I wrote this article to demonstrate that you can write some pretty cool Eclipse plug-in extensions without weeks of study. It is based off one of the four solutions presented in Chapter 26, Extending the Java Development Tools. Our book is divided in three parts (Using, Extending, and Exercises) and Part II is further subdivided into three sections (Fundamentals, Advanced, and Special Interests). This article attempts to present an advanced plug-in development topic in such a way that a reader with only passing knowledge of using Eclipse's Java development environment will have a good idea of what's involved in extending it themselves. Here's the abstract:

Extending Eclipse's Java Development Tools
The refactoring capability of Eclipse's Java development environment is one of the most useful features it provides. This article will introduce you to the steps for creating your own refactoring as a natural extension of Eclipse. Portions of the solution presented in this article were excerpted from the recently published book, The Java Developer's Guide to Eclipse.

And here's the first few paragraphs:

What is possible, where to start, and how to proceed
Eclipse has received much fanfare and accolades because of its powerful Java development environment. That -- coupled with the team environment and other base capabilities -- makes Eclipse a compelling integrated development environment, which is great news for Java developers. Moreover, Eclipse is an open source project. But what makes Eclipse truly exciting is the possibilities of extension that it offers you.
A number of commercially available products, based on Eclipse, show the practical implications of this way of delivering integrated products. IBM WebSphere Application Developer and Rational XDE, for example, demonstrate the impact that Eclipse has already had. These products and others based on Eclipse diminish the user's learning curve because of their similar user interface. Sure, this is valuable to large software houses, but what's in it for the "little guy"?
That's where the extensibility story of Eclipse gets interesting. Not just integration for those who have large development organizations, but also for anyone willing to invest some time in learning a few Eclipse frameworks. "Oh no," you may be thinking, "not more frameworks; I don't have the time to learn more frameworks." Don't worry; it will be quick and fairly easy. And before that little voice in your head has time to say it, no, this article will not be a trivial "hello world" extension of Eclipse. Rest assured, you'll see practical value and a clear demonstration of how you can enhance your productive use of Eclipse's Java development environment. You may even be a little surprised to see that it takes only a few dozen lines of code to do some fairly amazing things.
This article will show you what is possible and where to start, and give you a firm appreciation for what's involved in getting there. Though extending Eclipse is an advanced topic, you can start with only passing knowledge of how to use Eclipse's Java development environment (and be sure to check out the suggested reading in Resources for further study).
Your own easy refactoring of member visibility
Initially when writing code, I don't worry too much about categorizing method visibility as default (package), private, public, or protected. As I create methods, I make them all public. Only once I've finalized the organization of packages and finished refactoring methods -- whether that be by extracting new methods from existing code, pulling up or pushing down methods in the hierarchy, or moving them to another class entirely -- do I then review method visibility. I figure that until I know the final class shapes and have a little practical usage of the code, I don't want to declare what my "clients" might need. In other words, before sharing a new framework, one must decide what is implementation detail and what is necessary so others can extend it.
It would be handy if you could merely select methods in the Outline view, Hierarchy view, or wherever you see methods -- and with a click of a menu choice, set one or more methods to the desired visibility. Admittedly, I am accustomed to this capability from my VisualAge for Smalltalk days. The figure below shows an extension to Eclipse's Java development environment in the context of the Java editor's Outline view.

This is subtle, from a user's perspective, because of the natural way this was introduced into the user interface. There is no inkling that these new menu choices weren't part of Eclipse's original Java Development Tools (JDT). In fact, that's why the menu cascade is prefixed with "Soln:" -- so you can tell it's an extension! What's more, the developer doesn't have to remember that these choices are only available in a particular view or editor, because they will be shown anywhere a method is shown.
... see the rest on Tuesday.

Well, I gotta ride. I hope y'all find this article helpful and it encourages y'all to try your hand at plug-in development. I promise you that it ain't no stinkin' "Hello, World". Yeehaw! Giddy up! Let's ride!
-- Dan
[ July 18, 2003: Message edited by: Dan Kehn ]

[Ashik Uzzaman]

Awesome post!

[Dan Kehn]

Here's the URL to Extend Eclipse's Java Development Tools: What is possible, where to start, and how to proceed: http://www-106.ibm.com/developerworks/opensource/library/os-ecjdt/. The editor changed the title (no sense of irony I guess).
Feedback here is welcome.
-- Dan