Comparison shopping for an IDE

Given how much time you spend using an IDE, you probably have strong opinions about which IDE is the best. Some programmers might consider Emacs a quaint relic from the last millennium, while other programmers will abandon it only when their cold, dead fingers are pried off their keyboard. One IDE is better than another only to the extent that it makes you more productive, and for a programmer who has been coding C in Emacs for 20 years, that is a productive environment.

Because the Java language is relatively young, no long legacy of coding exists in any particular development environment (at least not yet!). The popularity of each of the various Java IDEs has tended to wax and wane in the race to provide new features, improve performance, and become easier to use. The most interesting new development has been the introduction of two free, extensible open source IDEs: Netbeans and Eclipse. These are rapidly approaching the capabilities of commercial offerings. Most developers won't need more than what these two excellent development platforms provide.

Back to top

Comparing Netbeans and Eclipse

The most recent versions of these two IDEs -- Netbeans 3.6 and Eclipse 3.0 -- have far more similarities than differences. They both have syntax checking, code completion, and code folding. They both let you compile, run, and debug your code. They both support Ant, CVS, and JUnit. Also, both now have integrated GUI builders, although Eclipse's is a separate component, the Visual Editor, that you must download separately. For more information about the Eclipse Visual Editor, see the article "Building GUIs with the Eclipse Visual Editor" listed in the Resources section later in this article.

The main differences between the two IDEs are that Netbeans has integrated Web development support, but Eclipse does not; and Eclipse has automated refactoring, but Netbeans does not. But even if it's important to you, the lack of a specific feature doesn't have to be a deciding factor. Because both of these IDEs are extensible with the use of plug-ins, you'll find free or inexpensive plug-ins available to fill in the gaps. Articles that show you how to obtain, install, and use plug-ins for developing Struts and Web applications with Tomcat are listed in the Resources section.

Many programmers prefer Eclipse because of its ease of use; the overall design of Eclipse keep the tools you need immediately at your fingertips. Many programmers also find Eclipse faster and more stable. Because these attributes are hard to quantify, though, you really need to try it out and judge for yourself whether Eclipse makes Java programming faster and easier for you.

Back to top

A matter of perspective

When you go swimming, the hardest step can be deciding to jump in. You know the water is going to be cold, but you also know that that feeling passes quickly and you'll soon be comfortable. In a similar way, when you first start working with Eclipse, you might find the user interface somewhat intimidating, with a limited set of options. How do you get started? The Eclipse user interface, or workbench, is based on the concept of a perspective, and you'll first need to understand this concept before you can use Eclipse effectively.

Netbeans, like many large computer applications, uses a number of different windows to let you perform different tasks. When you start, a Filesystems window at the top left of the screen allows you to add and open resources to your projects, and a main window to the right of it is for editing. More windows, such as an output window, open as needed, either automatically or because you choose to open them to perform different tasks.

Eclipse builds on this basic concept by allowing multiple arrangements of windows. 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. These task-specific arrangements of windows are called perspectives. In addition to views, each perspective can have different tool buttons and menu selections as appropriate.

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

Like Netbeans, the Resource perspective has a tree-oriented window at the top left that lets you navigate and manage resources, called the Navigator. This window, like most windows in Eclipse, is called a view. Initially, there are two other views in the Resource perspective -- an Outline view below the Navigator, and a Task view below the main editor area.

Eclipse distinguishes 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, shows where it is physically located in the file and package hierarchy, and another, the Outline view, shows (among other things) the class's methods and attributes. If you have multiple Java files, these views change as you switch between the different files in the editor.

Although it's easy to open new perspectives and switch between them, it isn't generally necessary because as you work, the perspective changes automatically when it's appropriate. (Eclipse politely asks 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 buttons, menus, and views from the UI tool 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. Both Eclipse and Netbeans use the word "project" to describe one of the main ways they organize your files and other resources, but they refer to fundamentally different things.

To understand Eclipse's use of the word "project," it's important to first understand that Eclipse is associated with a directory called workspace. When you first start Eclipse, you are prompted for the location of this 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 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 a workspace is recommended because it keeps things better organized, Eclipse 3.0 gives you 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.

Back to top

Let's start coding

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 get a Welcome screen. This leads to tutorials and other interesting items, 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 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 allows you to configure libraries and add other projects to the classpath 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 brings 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.
• Press Finish. (See Figure 2.)

You'll notice a number of different things after creating this class. First, a few "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.

Also notice that corresponding to each symbol in the left column 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. These correspond to the plus and minus signs that 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:

Note: 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.

Now, we'll add some code so we have something to play with. Add a line to the main() method creating a Vector called names. Since you haven't imported the Vector type, there will be a symbol in the left margin, a red box with an "X" combined with a yellow light bulb, as shown in 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 click Ctrl-1 (the QuickFix shortcut). A pop-up will appear 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.

An interesting thing about Eclipse is that it uses an incremental compiler to compile your code as you type it in. If you have syntax errors, it won't be able to interpret your code correctly, and won't be able to provide you with a QuickFix. For example, if you don't fix the import problem above, but instead continue by typing names on the next line, names are underlined with a red squiggle indicating a syntax error, but there will no longer be any indication that there is a problem with the previous line where map is defined.

Holding the mouse pointer over a syntax error like this brings up a hover tip describing the problem; in this case, it indicates that it is an incomplete statement requiring a semicolon. (This isn't all that's missing, of course, but it's a start.) You might consider this a feature: it encourages you to fix your errors as you go along. You don't have to do this, of course, but if you don't, you won't be using Eclipse as effectively as possible.

After making sure 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 just the same as it does in Netbeans: after typing the first part of a type or identifier, press Ctrl-Space and you see a list of options. Here it's especially useful if you've forgotten the name of the method you need -- is 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 probably worth explaining it 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.

The green line is an insertion point, and you can move the cursor to its location by pressing the Tab key. It's provided here because after you add an argument for add(), you'll presumably want to move past the parentheses to add more code or a semicolon.

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 have several options, one of which is to iterate over a collection. Select this and the code is inserted as shown in Figure 5:

Notice that the first instance of each identifier that Eclipse has added is enclosed in boxes. If you change these, Eclipse changes it 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 on 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.

Back to top

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, and 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 Netbeans) 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 asks if you want to change to this perspective. Check the box "Remember my decision" and then click Yes as shown in Figure 6:

Most of the views in the Debug perspective should be more or less familiar to you from windows in Netbeans, although they may have different names. The Debug view (not to be confused with the Debug perspective) shows the call stack, the Variables view shows the current state of the program's variables, and the Console view shows the program.

You'll also notice that there are tool buttons (Step over, Step into, and so on) for controlling execution in the Debug view's 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 brings 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 let you know 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 on 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 on 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

Netbeans has some code generation features that are similar to refactoring, such as the ability to generate getters and setters for class attributes. However, these differ from refactoring in that they add new functionality. Refactoring differs from automated code generation in that it restructures the code without changing the functionality.

If you have a comprehensive set of JUnit tests that your code passes, your code should continue to pass the same tests after the refactoring. (In some cases, the unit tests themselves may be changed by the refactoring, but the point is that this should happen automatically as well.) For more information about refactoring and an introduction to many of the refactorings available in Eclipse, see the article "Refactoring for everyone" listed in Resources.

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 below.)
• 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 adds 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, you now have two options. The first is 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. When you click 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 (see 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 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 also called greet(), they will be changed in the same way.

If you run the program now, it produces exactly the same result as before, like any proper refactoring should. What we've gained is the ability to print out and use different greetings 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);

Back to top

Using CVS

Although both Netbeans 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. In addition, Eclipse supports more client-server connection types than Netbeans. In particular, Netbeans only has built-in support for the pserver protocol, which is inherently insecure because is transmits passwords in the clear. Eclipse supports both pserver and ssh, which we look at next.

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 allows you to enter the information needed to connect to a CVS server (see Figure 11). 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 appears, with the option "Use existing repository location selection" checked. Below this, the repository that you entered before is selected. Click 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 lets you review what you are going to check in; if there are no problems, click Finish.
• A final dialog box notifies you that you have not yet committed your changes, and ask if you want to commit them. Click Yes.

You are now 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, click 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.

• Click Yes, if you haven't already.
• You are 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, and most dangerous 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 is better to use Eclipse's Team Synchronizing perspective, which presents 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 are notified that this task is associated with the Team Synchronizing perspective, and asked if you want to switch to this perspective. Check the "Remember my decision" and click 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 handles String differently than other objects perhaps) and in the meantime someone else checked out the code and made another change (to the main() method perhaps). You might not necessarily know 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 (see 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 as follows:

• 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

Feature-for-feature, Eclipse and Netbeans are well matched. In fact, because they are both extensible, any feature gaps between the two can be filled in with third-party plug-ins. The important difference between them lies in the way the user interface is designed. Eclipse is organized around the concept of a perspective that makes it easier to get the job done, because the appropriate tools (and only the appropriate tools) are close at hand. A number of additional features in Eclipse make it a more effective tool for Java programmers, such as QuickFix, QuickDiff, and easy navigation within source code using bookmarks or the class outlines. You'll also find strong support for CVS and refactoring in Eclipse 3.0, which you won't find in Netbeans. This should make a compelling case for any programmer, including current Netbeans aficionados, to try out and master Eclipse.

Resources

• Learn more at the Eclipse Web site and get a comprehensive listing of Eclipse plug-ins.
  
  
• The latest version of Netbeans is at the Netbeans 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 IntelligJ IDEA and JBuilder users migrate to Eclipse: Migrating from IntelliJ IDEA to Eclipse (developerWorks, September 2004) and Migrating from JBuilder 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

• Comparison shopping for an IDE
• Comparing Netbeans and Eclipse
• A matter of perspective
• Creating a new project in Eclipse
• Let's start coding
• Running and debugging your program
• Resource perspective revisited
• Refactoring
• Using CVS
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Open source on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers