Eclipse -- the open source alternative

Eclipse, the open source, extensible integrated development environment, has been attracting a lot of well-deserved attention lately. It's always had its supporters, something many people found baffling when it lacked features that were long common in other IDEs such as JBuilder. Developing software is mostly (but not entirely) about writing code. No matter how many features an IDE provides, if it gets in the way of that essential task, it's going to hinder rather than help the programmer. That's why many programmers have long preferred a simple text editor to an IDE.

Interestingly, many early adopters of Eclipse migrated from text editors rather than from other IDEs. This, of course, explains why they didn't mind the lack of features. For many, this was the first IDE that didn't get in their way and simply let them get on with their work.

A more interesting question is whether Eclipse is as good as IDEs that cost money. The answer is a qualified "yes." First, it depends on what you intend to use it for. If you just need to do basic development, there's no need to look further. For coding, debugging, refactoring, unit testing, and so on, it matches or beats everything else available. Like the free JBuilder X Foundation edition, Eclipse has code completion, code templates, and integrated support for refactoring, Ant, CVS, and JUnit. In fact, you'll probably find that Eclipse has better support for many of these features than JBuilder does. For example, Eclipse has more refactorings and better support for merging local code with a CVS server.

Beyond the essentials, and depending on what features you need, the story gets a bit more complicated. One of the benefits of Eclipse being open source and extensible is that many plug-ins, both open source and commercial, are available to extend it. If you need a feature that the basic Eclipse IDE doesn't have, you can probably find a free plug-in that does the job at least adequately -- this is true of Web and J2EE development, for example. (For articles about obtaining, installing, and using plug-ins for Struts and Web application development, see the Resources section later in this article.)

In addition to free plug-ins, you can find many reasonably priced commercial plug-ins for Eclipse. If you only need a few advanced features, and don't find the free offerings satisfactory, you might find it more economical to purchase plug-ins à la carte from a third-party vendor rather than buying a complete enterprise IDE package. Because of its popularity and open source nature, Eclipse has the edge over other IDEs in this regard -- hundreds of plug-ins, free and commercial, are available. You can find most of these by visiting the Eclipse plug-ins page listed in Resources.

One feature that Eclipse 3.0 lacks at the time of writing, and which JBuilder has long had, is a visual tool for building user interfaces. This lack is being actively addressed. The Eclipse Visual Editor (VE) release 0.5, which supports AWT/Swing, is available for Eclipse 2.1.x. now and a version for Eclipse 3.0, release 1.0, will be available soon. VE 1.0 will be available as a separate download on the Eclipse Web site and will support not only AWT/Swing, but SWT as well. For more information and a preview of VE, see the Visual Editor article listed in Resources.

Back to top

Getting started with Eclipse

Eclipse is little different from other IDEs because it introduces a new and unfamiliar level of abstraction to the user interface: the perspective. Eventually, you'll find that this concept streamlines navigation through Eclipse's rich feature set by removing options that aren't relevant to the task at hand and letting you focus on what you need to do.

To explain, we'll need to introduce some more Eclipse lingo. The Eclipse development environment -- that is, the main Eclipse window as a whole -- is called the workbench. Inside this main window are various panes, called views, which display console output, outline views of your project, and so on. Multiple views are often stacked in a notebook arrangement and can be selected using tabs. In addition to views, the workbench has one special pane, the editor, where you can edit different types of documents such as source code.

So far, this description of the Eclipse workbench doesn't sound much different from the way JBuilder is arranged. As you perform different tasks, such as coding, debugging, or merging your code changes with those in a centralized code repository, you can use an arrangement of windows chosen specifically for that task. This task-specific arrangement of windows is called a perspective. This is similar to the function of the tabs below the editor in JBuilder, except that in Eclipse the whole workbench can change, including the main toolbar and menu.

The basic perspective, the one that Eclipse starts with when you dismiss the initial Welcome screen, is called the Resource perspective, as shown in Figure 1:

Back to top

A matter of perspective

Like JBuilder, the Resource perspective in Eclipse has a tree-oriented view; the Navigator, at the top left (which is not apparent here, obviously, because we haven't created anything) that lets you navigate and manage resources. Initially, the Resource Perspective has two other views -- an Outline view below the Navigator and a Task view below the main editor area.

Eclipse makes an important distinction between views and editors. A perspective can have many views, but it can have only one editor, which is the focal point of the workbench. Generally speaking, if you have a file open in the editor, the other views reflect different aspects of that file. If it's a Java™ file, and you're in the Java perspective, one view, the Package Explorer, will show where it is physically located in the file and package hierarchy, and another, the Outline view, will show (among other things) the class' methods and attributes. If you have multiple Java files, these views change as you switch between the different files in the editor.

Even though it's easy to open new perspectives and to switch between them, it isn't generally necessary because as you work, the perspective changes automatically when it's appropriate. (Eclipse will politely ask your permission first, of course.) You'll see this in a minute, when we create a Java project, and later, when we debug a Java program. Once you get used to perspectives, you'll probably find that they are a smooth and natural way to work because they eliminate from the UI any tool buttons, menus, or views that are not appropriate for the job at hand. This makes it much easier to find the relevant tools.

Back to top

Creating a new project in Eclipse

To start working in Eclipse, you must first create a project. When you first start Eclipse, you are prompted for the location of a workspace directory (assuming you don't specify it as a command-line option) and Eclipse creates it for you if it doesn't already exist. By default, all your information -- some Eclipse-specific information, your Java source and class files, images, and so on -- is stored in subdirectories, or folders, in this workspace directory. Each folder in this directory corresponds to a project and typically contains a stand-alone application, a Web application, or a component of some type.

Although using the workspace for your projects is recommended because it keeps things better organized, Eclipse 3.0 introduced the ability to create or specify existing directories outside the workspace to use as project folders. This can be especially helpful if you are migrating from another IDE that doesn't encourage a strictly organized directory structure.

If you want to follow along, and haven't started Eclipse yet, start it now. If you haven't installed Eclipse yet, you can refer to the article "Getting started with the Eclipse Platform" listed in Resources. The first time you run Eclipse, you'll get a Welcome screen. This leads to tutorials and other interesting information that you might want to come back to, but dismiss it for now by clicking the "X" in the tab at top; you can recall this screen later by selecting Help > Welcome from the main menu.

As previously shown in Figure 1, you will be in the Resource perspective. There's always more than one way to do things in Eclipse -- using shortcuts, toolbars, or menu selections -- but throughout this article we'll generally use menus. Here we'll create a project by using a context menu as follows:

• In the Resource perspective, right-click in the Navigator view and select New > Project.
• Select Java Project in the New Project wizard.
• Enter a name for the project, such as "Hello."
• Notice that in the Location section, you have the option to create the project in an external location, but accept the default, "Create project in workspace."
• Also, in the Project Layout section, accept the default selection, "Use project folder as root for sources and class files." Generally, it's better to use separate directories (typically src and bin) but we'll keep things simple for now and accept the default.
• Clicking Next will allow you to configure libraries and add other projects to the classpath that this project depends on, but we don't need to do that. Instead click Finish.
• After a moment, Eclipse asks, "This kind of project is associated with the Java Perspective. Do you want to switch to this perspective now?" Check the box marked "Remember my decision" and click Yes.

Now that we have a project, we can create a class. We'll create a variation of the standard "Hello, world" program.

• Right-click the Hello project and select New > Class. This will bring up the New Class wizard.
• Enter com.example.hello as the package name.
• Enter HelloObject as the class name.
• Leave java.lang.Object as the superclass.
• Make sure that the option to create a stub for a main() method is checked.
• Click Finish. See Figure 2.

Although using a workspace is recommended because it keeps things better organized, Eclipse 3.0 introduces the ability to create or specify existing directories outside the workspace to use as the project folder. This can be especially helpful if you are migrating from another IDE that doesn't encourage a strictly organized directory structure.

You'll notice a number of different things after creating this class. First, a couple of "TODO" items appear in the file to indicate the need to customize the templates that generate comments. Like other annotations such as bookmarks, breakpoints, and syntax problems, these are indicated by a symbol in the left margin of the editor. Later, you should modify the code template for this comment according to the directions, but leave it as it is for now.

You should also note that corresponding to each symbol in the left column, there is a small box in the same color in the right column. While the left margin marks only things currently visible in the editor, the right margin shows everything marked in the file. If you had a long file with an error at the end, there would be a small red box at the bottom of the right margin regardless of which part of the file was showing in the editor; clicking on this would take you to the error.

In addition to the check mark symbols in the far left margin, there are small triangles in a column to the right of these, just like in JBuilder, to control code folding. Clicking on the first triangle next to the comment preceding the class definition deletes the comment, replacing it with an ellipsis as shown in Figure 3:

As you work with code in Eclipse, you'll notice yet another column in the left margin between annotations and the code folding controls. This contains colored bars that let you compare the current code in the editor with previous versions of the code. This feature is called QuickDiff. You might want to explore this on your own later.

Checking out syntax checking and code completion

We'll need to add some code so we have something to play with. As you'll see, Eclipse provides the equivalent of JBuilder's CodeInsight, ClassInsight, and other features that assist you in writing source code.

Add a line to the main() method creating a Vector called names. Because you haven't imported the Vector type, there will be a vaguely familiar symbol in the left margin, a red box with an "X" combined with a yellow light bulb. (If you squint a little, you might even mistake it for the gold key and red circle with an exclamation point that JBuilder uses. See Figure 4.)

The "X", of course, means there is a problem, but the light bulb means Eclipse has a QuickFix: one or more suggestions for solving the problem. Either click the light bulb or click Vector and press Ctrl-1 (the QuickFix shortcut). A pop-up appears, listing possible fixes including: "Import Vector," "Rename in File," and "Create Class Vector." You can double-click the first suggestion to have Eclipse add an import statement for you.

After ensuring that Vector is properly imported, begin the next line again by typing names. You can use code completion to locate the proper method for adding items to the Vector names.

Code completion in Eclipse works pretty much the same as it does in JBuilder, but by default it's a little slower. After typing the period after names, you have to wait half a second for a list of method names to appear. (This is because Eclipse tries to stay out of your way if you're typing quickly. You can change this by selecting Windows > Preferences > Java > Editor from the main menu and changing the Auto activation delay to another value in milliseconds.) If you want a suggestion, and don't want to wait, you can also press Ctrl-Space to see a list of options immediately. Here code completion is especially useful if you've forgotten the name of the method you need: was it put() or add()?

Of course, it's add() that you want, and after you select the single parameter version from the list, you'll notice that Eclipse not only completes the method name, it also adds open and closing parentheses, places the regular cursor inside the parentheses, and draws a green line (resembling a cursor) after the closing parentheses. You'll see this green line often as you enter code in Eclipse, and while you can simply ignore it with no apparent effect, it's worth explaining now. If you write your own code completion templates later (something that is quite easy to do in Eclipse), you'll probably want to take advantage of this feature.

Add the hard-coded string "Moe" to the names Vector. When you type the open quote, Eclipse helpfully provides the closing quote, moves the cursor between the two quotes, and provides a new insertion point after the closing quote. After typing Moe, press Tab to move past the close quote. The first insertion point, after the closing parenthesis, now reappears. Press Tab again to move to the end of the statement, and type a semicolon.

Similarly, add two more names to the names vector, Curly and Larry. The code should now look like this:

			
      public static void main(String[] args) {
            Vector names = new Vector();
            names.add("Moe");
            names.add("Curly");
            names.add("Larry");
            }
      }

One of the nice things about code completions in Eclipse is that they are aware of their context. Here, if you type for and press Ctrl-Space, you will have a several options, one of which is to iterate over a collection. Select this and the code to iterate over the names vector will be inserted as shown in Figure 5:

Notice that the first instance of each identifier Eclipse has added is enclosed in a box. If you change one of these, Eclipse changes the identifier every other place it appears. If you rename iter to i, the other instances automatically change as well. The only thing you must change here is type to String, but you might also want to change element to name as well. You can press Tab and Shift-Tab to move between each of these. Here is what the code looks like after making these changes, and adding a call to an as-yet-nonexistent method greet():

			
            for (Iterator i = names.iterator(); i.hasNext();) {
                  String name = (String) i.next();
                  greet(name);
            }

Next, use Eclipse's QuickFix (by clicking greet and pressing Ctrl-1, for example) to generate a method stub for greet(), and add code to the stub as follows:

			
      private static void greet(String name) {
               System.out.println("Hello, " + name);
     }

At this point, the code should have no errors. Right-click in the editor and select Save from the context menu.

Running and debugging your program

As mentioned, Eclipse uses an incremental compiler, so it is not necessary to explicitly compile your Java files. The compiled class files are saved when you save your Java files. To execute your program, select the Java file either in the editor or in the Package Explorer then select Run > Run As > Java Application from the main Eclipse menu. (Notice that this is different from the Run > Run... menu option, which we'll see later.) This should produce the following output in the Console view below the Editor:

			
      Hello, Moe
      Hello, Curly
      Hello, Larry

Running a simple program in the debugger is similar. First, set a breakpoint at the call to the greet() in the main() method by double-clicking (not single-clicking like JBuilder) in the left margin. If you want to set a conditional breakpoint -- one that stops when a particular expression such as i==2 is true, or one that stops after a specific number of hits -- you can right-click on the breakpoint and select Breakpoint properties from the context menu.

To start debugging, select Run > Debug As > Java Application from the main menu. Because Eclipse has a Debug perspective that is better suited for debugging than the Java perspective, it will ask if you want to change to this perspective. Check the box "Remember my decision" and then click Yes. See Figure 6.

You'll notice that the views in the Debug perspective have equivalents in JBuilder, but because the entire Eclipse workbench is dedicated to debugging in this perspective, you don't have to switch between different tabs to see variables, the call stack, and the output console.

Also notice that the call stack is shown in a view called the Debug view (not to be confused with the Debug perspective that contains it) and that there are tool buttons (Step over, Step into, and so on) for controlling execution in its tool bar. The reason these controls are located here, together with the call stack, is that if you are debugging more than one program (or instance of a program), or a program with multiple threads, you can select the program or thread to control by clicking on it in the call stack. If you like, you can play with this by launching this example program again, without terminating the first instance.

Sometimes you don't want to (or can't) run a program using the simple menu selection Run > Run As > Java Application. If you need to pass arguments to either the program or the VM it runs under, you'll instead need to use the Run > Run... menu option. This will bring up a dialog that you can use to set these and other options as shown in Figure 7:

Back to top

Resource perspective revisited

One of the nice things about perspectives is that they keep your screen free from clutter. You may have noticed, for example, that class files don't appear in the Package Explorer in the Java perspective. Assuming Eclipse is able to compile your Java files (and it'll tell you if it can't), you really don't need to do anything with them in order to build, run, and debug a program. But once you're done, you may want to copy the class file to another directory or zip it up to send it to someone else by e-mail.

One way to do that is to go outside Eclipse, since you know where your workspace directory is -- there is nothing special about this directory or the Hello subdirectory that your project files are kept in. But you can also do this from inside Eclipse by selecting File > Export from the main menu. But first, you'll need to return to the Resource perspective in order to see all your files. You can do this most easily by clicking the Resource perspective button in the top right corner of the workbench as shown in Figure 8:

Here you'll see several files that were hidden in the Java perspective: your class file, HelloObject.obj, and two metadata files that Eclipse uses to store your project information (.project and a .classfile). To zip your class file:

• Click HelloObject.class to select it.
• Select File > Export from the main menu.
• Select Zip file as the export destination and click Next.
• The file to zip should already be selected in the following screen; in the field labeled "To zip file:", browse or enter a path and file name for the zip file you want to create and click Finish.

Back to top

Refactoring

As with JBuilder, one of Eclipse's most powerful features is the ability to refactor code. While Eclipse has more refactorings than JBuilder, and JBuilder has one or two that Eclipse doesn't, they have the most important ones in common. For more information about the refactorings available in Eclipse (and refactoring in general), see the article "Refactoring for everyone" listed in Resources.

If you're used refactoring in JBuilder, you'll find that it's essentially the same in Eclipse, except for the fact that Eclipse uses a wizard to guide you through the process. Using this wizard, you'll have the opportunity to use Eclipse's powerful comparison dialog box to navigate between the changes that Eclipse proposes to make and you can veto or accept each change.

We'll take a quick look at one relatively simple refactoring here: Change Method Signature. We'll use this to change the type of the String parameter in the example program's greet() method to Object and add an additional parameter of type String for the greeting that it prints. To do this:

• Select the greet() method by right-clicking its name in the editor or in the Outline view.
• Select Refactor > Change Method Signature... from the context menu. (See Figure 9.)
• In the table labeled Parameters, click the type String and change it to Object.
• Change the name of the parameter to object.
• Click the Add button on the right; this will add a new entry below the existing parameter. Change its type to String, its name to greeting, and the default value to "Welcome, ".
• We want the new greeting parameter to be the first parameter; verify that it is still the selected parameter and click the Up button. (Or select the original parameter and click the Down button.)

As with all refactorings in Eclipse, you now have two options. The first is what you might call the "Just Do It" option. Normally, Eclipse gets its refactorings right and in the rare case that it doesn't, you can always undo it using the Refactor > Undo menu selection. (Although this offer is only good for a limited time after refactoring. If you change any of the files that are involved, you won't be able to undo the refactoring anymore.) If you are comfortable with this, you can simply click OK. Normally, this is the easiest thing to do, but don't do it now.

The second option, the "I want to micromanage" option, is interesting to see at least once. By clicking Preview, Eclipse shows you a dialog box that lets you select specific changes in all affected files at the top, and a side-by-side, before-and-after comparison of the selected file below this. (In this case, of course, there is only one file.) Here you can examine the proposed refactoring file-by-file, change-by-change, and approve or reject each change individually as shown in Figure 10. Leave all the changes checked and click OK.

This is what the code looks like after refactoring:

			
      public static void main(String[] args) {
            int x = 100;

            Vector names = new Vector();
            names.add("Moe");
            names.add("Curly");
            names.add("Larry");
            for (Iterator i = names.iterator(); i.hasNext();) {
                  String name = (String) i.next();
                  greet("Welcome, ", name);
            }
      }

      /**
       * @param greeting TODO
       * @param object
       */
      private static void greet(String greeting, Object object) {
                  System.out.println("Hello, " + object);
      }

Notice that the refactoring updated the greet() method call in the main() method and used to the default value, "Welcome, " for the first parameter, in addition to changing the method itself. If there are other files in the project and they are called greet() too, they will be changed in the same way.

If you run the program now, it will produce exactly the same result as before, like any proper refactoring should. What we've gained is the ability to print out and use a different greeting each time we call the greet() method, but this is a functional code change that we have to make ourselves, by changing the System.out.println() call as follows:

System.out.println(greeting + object);

Later, we might want to change the way that object gets printed, depending on what type of object it is. It works fine for strings, but if it's something else, the object will gets converted to a string using the object's toString() method. Sometimes this will produce an undesirable result.

Back to top

Using CVS

Although both JBuilder and Eclipse have support for CVS and other version control systems, Eclipse provides a much more elaborate interface using two separate perspectives. The first is a CVS Repository Exploring perspective for choosing CVS repositories and modules to connect to and exploring the files they contain. The second is a Team Synchronizing perspective for merging changes into the repository. Although this may make CVS a little harder to use initially, this approach encourages a disciplined and structured workflow.

Another difference is that Eclipse is fairly strict about the type of CVS repository it supports. First, it does not support a local repository; that is to say, it will not access a CVS repository directly on disk but must use a client-server connection -- specifically using either the pserver or ssh protocol. Of these, ssh is recommended because it is more secure than pserver because the latter transmits the password as clear text. Conveniently, Eclipse provides a built-in client for both of these protocols.

To begin, you'll need access to a CVS repository and the information necessary to connect to it. Open the CVS Repository Exploring perspective by selecting Window > Open Perspective > Other from the Eclipse main menu and selecting CVS Repository Exploring. This perspective has several interesting views, but the principal one is at the top left, CVS Repositories. Right-clicking here and selecting New > Repository Location will allow you to enter the information needed to connect to a CVS server (see Figure 11). You'll notice that to use ssh, you need to select Eclipse's extssh connection type.

To create a new CVS module from an Eclipse project:

• Switch to the Java or Resource perspective.
• Right-click the project name and select Team > Share Project... from the context menu.
• A dialog box will appear, with the option "Use existing repository location selection" checked. Below this, the repository that you entered before will be selected. Press Next.
• In the dialog box that follows, accept the option to use the project name as the module name and click Next.
• The next dialog box will let you review what you are going to check in; if there are no problems, click Finish.
• A final dialog box will notify you that you have not yet committed your changes, and ask if you want to commit them. Click Yes.

You will now be notified that there are six resources that are not yet under version control. You can simply answer Yes if you like, but if you're curious to find out what these resources are, press Details first. You'll find that these are the two Eclipse metadata files: .project and .classpath, the Java source file, HelloObject.java, and the nested folders that the Java source file is stored in (corresponding to its package): /Hello/com, /Hello/com/example, and Hello/com/example/hello.

• Press Yes, if you haven't already.
• You will be prompted for a comment; enter "Initial version".

After you've checked files into or out of CVS, and have worked on them some more, you'll need to make sure that your changes don't conflict with anyone else's before you check them; in fact, if conflicting changes do exist, CVS will not allow you to check them in.

You can resolve and merge your code with the repository in two ways. The simplest way is to simply update your local files with changes from the CVS repository by right-clicking your project and selecting Team > Update from the context menu. If there are changes, they will automatically be merged into your files using the diff format (lots of greater than and less than signs marking which lines are in your code but not in the repository, and vice versa). Trying to straighten this out would be tedious and error prone.

It's better to use Eclipse's Team Synchronizing perspective, which will present you with changed files side-by-side, to allow you to review and accept or reject changes in either file. To do this:

• Right-click the project name and select Team > Synchronize with Repository from the context menu.
• You will be notified that this task is associated with the Team Synchronizing perspective, and asked if you want to switch to this perspective. Check "Remember my decision" and press Yes.

Like most other perspectives, the view that you want to look at first is the one in the top left of the workbench, in this case the Synchronize view. At the top are several tool buttons, including Incoming Mode, Outgoing Mode, Incoming/Outgoing Mode, and Conflicts Mode. Which mode is selected initially depends on whether there are changes in the repository, changes in your local code, or changes in both (and whether or not the changes in both conflict). The mode determines which files are shown in this view: changed local files, changed repository files, or both. This may sound confusing, but in practice you don't really need to worry about the details; the important thing is that this acts to filter out unnecessary information. You'll only see the files that you need to review in order to bring your source code up to date with the repository.

Suppose that you add some code to HelloObject (so that it, for example, it handles String differently than other objects) and in the meantime someone else checks out the code and makes another change (to the main() method, for example). You might not necessarily be aware of this, but before you check in your file, you could right-click it and select Team > Synchronize with Repository.... This opens the Repository Synchronizing perspective (with your permission, of course) and shows you a side-by-side comparison of your local file and the file in the Repository as shown in Figure 12:

Here you can review each change in each file, and either copy it to your source by clicking the Copy Right to Left tool button in the Java Source Compare view or by editing the local file manually as appropriate. When you are satisfied with your merge, mark the file as merged by right-clicking the file name in the Synchronize view and selecting Mark as Merged from the context menu.

Once you've resolved any conflicts and merged all the files in the Synchronize view, you should return to the Java view and verify that the project builds and runs correctly before checking your code in. To check your code in:

• Right-click the project name (or a file name to commit a single file) and select Team > Commit from the project menu.
• Enter a comment when prompted. (Note that if you are checking in the project and multiple files have changed, this comment will be applied to all files. If you want to enter comments for individual files, you'll need to check the files in individually.)

Back to top

Summary

Both Eclipse 3.0 and Borland's JBuilder X Foundation edition are feature-rich Java IDEs that provide syntax checking, code assistance, and code generation for coding, plus support for refactoring, Ant, unit testing, and CVS. And soon, the Eclipse Visual Editor 1.0 for building GUIs using either AWT/Swing or SWT will be available. But there are some important differences between the two.

One important difference lies in the way the Eclipse user interface is designed using the concept of a perspective -- a collection of views, editors, and other UI elements that are best suited for performing a specific task. This makes it easier to get the job done because the appropriate tools (and only the appropriate tools) are close at hand.

Another important difference is that Eclipse is an open source project. Because of this, Eclipse has attracted a large community of developers that are creating plug-ins, both free and commercial, for Eclipse. If you need a feature, anything from aspect-oriented development support or a built-in MP3 player, you are likely to find a free plug-in that extends Eclipse to provide it.

Resources

• Learn more at the Eclipse Web site and get a comprehensive listing of Eclipse plug-ins.
  
  
• The latest version of JBuilder Foundation is at the Borland Web site.
  
  
• David's article Getting started with the Eclipse Platform (developerWorks, November 2002) provides a history and overview of Eclipse, including details on how to install Eclipse and plug-ins. Also his book, Eclipse In Action: A Guide for Java Developers (Independent Pub Group, 2003), is a must-read for Java developers using Eclipse.
  
  
• For an overview of Visual Editor and the technology behind it, along with a short demonstration of Visual Editor 0.5's features for building AWT/Swing applications and a preview of the SWT support in Visual Editor 1.0, see Build GUIs with the Eclipse Visual Editor (developerWorks, May 2004).
  
  
• Refactoring for everyone (developerWorks, September 2003) shows how and why to use Eclipse's automated refactoring features with examples of all the refactoring features in Eclipse 2.1.x and most refactoring features in Eclipse 3.0.
  
  
• Using Eclipse as development environment with Jakarta Tomcat (developerWorks, May 2004) shows how to develop Tomcat applications using Eclipse and the Sysdeo Tomcat plug-in. Instructions are included for installing Tomcat and the plug-in.
  
  
• Debugging with the Eclipse Platform (developerWorks, May 2003) provides an overview of debugging in Eclipse.
  
  
• Developing Struts with Easy Struts for Eclipse (developerWorks, April 2004), shows how to develop Struts applications in Eclipse using the Easy Struts plug-in. Instructions are included for installing Struts and the plug-in.
  
  
• David has written similar how-to articles to help Netbeans and IntelligJ IDEA users migrate to Eclipse: Migrating from Netbeans to Eclipse (developerWorks, September 2004) and Migrating from IntelliJ IDEA to Eclipse (developerWorks, September 2004).
  
  
• Visit the developerWorks Migration station for many other migration paths to open standards-based development.
  
  
• In addition to all Eclipse articles on developerWorks, find more resources for developing with Eclipse in the developerWorks Open source zone and developerWorks Java zone.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Eclipse -- the open source alternative
• Getting started with Eclipse
• A matter of perspective
• Creating a new project in Eclipse
• Resource perspective revisited
• Refactoring
• Using CVS
• Summary
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Open source on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers