Extending Eclipse's Java development tools

Because Eclipse has a powerful Java development environment, it is well received by people alike. This Java development environment (plus the team environment and other basic functionality) makes Eclipse a compelling integrated development environment, which is good news for Java developers. Also, Eclipse is an open source project. But what really excites people about Eclipse is that it offers the possibility of expansion.

Many of the commercial products based on Eclipse show the real meaning of this approach to providing integrated products. For example, IBM WebSphere application Developer and Rational XDE illustrate the impact Eclipse has. These products and other Eclipse based products reduce the user's "learning curve" because they have a similar user interface. Of course, this is valuable for large software companies, but what's the use for small companies or individuals?

This is where Eclipse scalability is of interest to people. Not only do companies with large development organizations can use it to integrate, but anyone willing to take the time to learn a few Eclipse frameworks can take advantage of that ability. "Oh no," you might think, "don't mention any more frames; I don't have time to learn more." "Don't worry about it, it's very quick and quite easy to learn." Before your other doubts begin to form in your mind, it is a bit of a statement that this article is by no means a worthless "hello World" extension to Eclipse. Rest assured that you will see real value and a clear demonstration of how to enhance the productive use of the Eclipse's Java development environment. You may even be a little surprised to find that there are just dozens of lines of code to accomplish some pretty amazing things.

This article will show you what is possible and where to begin, and will provide you with a reliable assessment of what you need to start with. Although extending eclipse is an advanced topic, you just have to understand how to use the Eclipse's Java development environment.

You easily refactor member visibility

When I first wrote the code, I didn't worry too much about whether the visibility of the method was classified as default (package), private, public, or protected. When I create a method, I make them public. It is only when I finalize the organization of the package and refactor the method-whether by extracting new methods from existing code, if you move the method up or down in the hierarchy or move the method whole to the other class-I will re-examine the visibility of the method. I think I don't want to declare what my "customers" might need before I know what the final class looks like and actually use the code. In other words, before you share a new framework, you must determine what the implementation details are and what is required so that no one can extend it.

If you simply select a method in Outline view, hierarchy view, or anywhere you view the method-and then by clicking the menu option, you can set one or more methods to the desired visibility-then this can be very handy. Admittedly, I'm used to this feature that I learned during my time using VisualAge for Smalltalk. Figure 1 shows an extension of the Outline view context for the Java editor in Eclipse's Java development environment.

Figure 1. Extensions to the context menu for a method

This is tricky from a user's perspective because it's a natural way to introduce a user interface. There is no hint that these new menu options are not part of Eclipse's original Java development tool (Java Development TOOL,JDT). In fact, that's why the menu cascade uses the "Soln" prefix-so you can tell if it's an extension! Also, developers do not have to remember that these options are available only in a particular view or editor because they can be displayed wherever the method is displayed.