1.7. Writing Code
Now that your first Java project has created and you have explored different ways to navigate the system and find the items needed, it is time to start using Eclipse tools to write new code. Eclipse supports a number of different editor types, both internal and external, for editing types of resources. Double-clicking on a Java file, for example, opens the Java editor (see Figure 1-37).
Figure 1-37. Java editor.
1.7.1. Java editor
The Java editor provides many features that focus on the job of editing Java code, including the following:
Many former VisualAge for Java users loved the ability of that IDE to show only a single method at a time rather than the entire Java file. The Eclipse Java editor supports the same capability via the Show Source of Selected Element Only toolbar button. For it to work, you must give focus to an editor since the button is not enabled until you're actually editing some code. This is one of those options in Eclipse that should be a workspace preference rather than a toolbar button.
220.127.116.11. Colored syntax highlighting
The colored syntax highlighting feature controls how Java code will be depicted. Independent control over color and font style (plain or bold) is provided for multi- and single-line comments, keywords, strings, characters, task tags, and Javadoc elements via the Java > Editor > Syntax Coloring preference page (see Figure 1-38).
Figure 1-38. Syntax Coloring preference page.
The code formatting feature controls how Java code will be formatted any time the Source > Format command is issued. A variety of options are provided for controlling brace position, new lines, line length, and white space usage through use of the Java > Code Style > Formatter preference page (see Figure 1-39).
Figure 1-39. Code Formatter preference page.
Alternate code formatters are available, including JIndent integration into Eclipse (www.javadude.com/tools).
The import organization feature provides an easy way to clean up the import statements within a Java file. New imports can be added using the Source > Add Import command, and existing imports can be cleaned up using the Source > Organize Imports command. The Java > Code Style > Organize Imports preference page (see Figure 1-40) provides a means to set the default order of import statements and the threshold above which wildcard imports will be used.
Figure 1-40. Organize Imports preference page.
Set the threshold to 1 to cause packages to be imported with ".*" immediately, or keep the default value at 99 to always import each type individually depending on your coding style.
The context-sensitive code assist feature can help speed up the creation of Java code quite dramatically. It can complete class names, method names, parameter names, and more. In Eclipse 3.2, CamelCase patterns, such as NPE, will expand to full class names such as NullPointerException.
To use it, position the cursor at a location in your Java code needing a suggestion and select either the Edit > Content Assist command or hold the Ctrl key down while pressing the Space key. This opens the popup code assist window (see Figure 1-41).
Figure 1-41. Code assistance in action.
If the code assist window fails to open and the feature just beeps at you instead, check your Java build path and then check your code because it may have so many problems that the compiler cannot make sense of it. Remember, the Java compiler is always working in the background!
The Java > Editor > Code Assist (Content Assist under Eclipse 3.2) preference page (see Figure 1-42) provides a number of options to control how the code assist feature acts when invoked.
Figure 1-42. Code Assist preference page.
The "quick fix" feature provides a way to easily fix common problems within the Java editor. Any time a problem is detected that can be fixed, a lightbulb icon is displayed in the marker bar (left vertical ruler) of the editor. Clicking on the icon opens a popup quick fix window (see Figure 1-43). Selecting the appropriate one from the list applies that fix to the Java source.
Figure 1-43. Quick fix in action.
Dozens of built-in quick fixes are available, including:
To use a template, position the cursor at the desired position in your Java code, start to type the name of the template, and press Ctrl+Space. This opens the popup content assist window (see Figure 1-44). Note that some templates are parameterized with user-defined variables. Once a template has been expanded, use the Tab key to move between variables.
Figure 1-44. Template expansion in action.
As an example, open the HelloWorld class that was created in Section 1.4.4, Using the Java Class wizard, on page 24 then enter "sysout" and press Ctrl+Space. This expands the sysout template to System.out.println(); with the cursor placed between the two parentheses. Type "Hello World" and press Ctrl+S to save your changes. This application will be run in Section 1.9, Running Applications, on page 54.
The Java > Editor > Templates preference page (see Figure 1-45) provides a place to add new templates and edit existing ones.
Figure 1-45. Templates preference page.
To add a new template, click the New button to open the Edit Template dialog (see Figure 1-46). Enter the name for the pattern in the Name field, its description in the Description field, and the code pattern itself in the Pattern field (note that code assist is not case-sensitive).
Figure 1-46. Edit Template dialog.
Eclipse supports two types of patterns, Java and Javadoc. Select the pattern type from the Context drop-down list. The Insert Variable button pops up a list of variables that can be inserted into the template. Click the OK button to add the template to the template list.
Some third-party plug-ins provide enhanced templates known as patterns (see Appendix A).
Refactoring is the process of changing a software system to improve its internal structure and reusability, without altering the external behavior of the program. It is a disciplined way of cleaning up code that minimizes the chances of introducing bugs. In essence, when developers refactor, they are improving the design of the code. Eclipse provides a very powerful and comprehensive collection of refactoring tools that make refactoring operations quick, easy, and reliable.
The Eclipse refactoring commands are available either from the Java editor's context menu or from the Refactor menu that is available from the main menu bar anytime a Java editor is open. The Refactor menu (see Figure 1-47) includes more than a dozen different refactoring commands that modify some aspect of a Java element and then update any references to it elsewhere in the workspace.
Figure 1-47. Refactor menu.
The refactoring commands that are supported include the following:
To use any refactoring command, select the Java element or expression that you would like to refactor and then select the refactoring command. Each refactoring dialog collects information appropriate to the task it needs to do. Once you have supplied that information (for example, the new method name as shown in Figure 1-48), click the OK button to complete the refactoring.
Figure 1-48. Rename Method dialog.
To preview the transformations that will be made by a refactoring method before they are committed, click the Preview button prior to clicking the OK button. The refactoring preview shows a hierarchy (a checkbox tree list) of the changes that will be made with text panes showing a before and after view of the affected code (see Figure 1-49). If you want to exclude a particular change from the refactoring operation, uncheck it in the tree list.
Figure 1-49. Rename Method preview.
Clean Up Wizard
Eclipse 3.2 adds a Clean Up wizard that will fix multiple source problems (such as removing unused private fields and local variables) simultaneously. Access it using the Source > Clean Up... command.
Every time you make a change to a file and save it, a snapshot of that file at that moment in time is recorded to the Eclipse local history. This provides a way to revert back to an earlier version of a file or to compare the current version with an earlier version to see the changes that have been made. Every entry in the local history is identified by the date and time it was created.
Note that "local history" is really local to the machine; it is never stored in CVS or another source code repository. This means that the history is only available to you, not to other users. This might be a surprise to VisualAge for Java or ENVY users who expect "method editions" to be available in the repository.
External File Warning
Local history is only saved for the files stored within your workspace. If you use Eclipse to edit external files, no local history is saved.
To compare the current state of a file with an earlier version, right-click on the file and select the Compare With > Local History... command from the context menu. This opens the Compare with Local History dialog (see Figure 1-50). Select any item in the history list to see a comparison relative to the current state of the file.
Figure 1-50. Compare with Local History dialog.
To replace the current version of a file with an earlier version, right-click on the file and select the Replace With > Local History... command from the context menu. This opens the Replace from Local History dialog, which is almost identical to the local history comparison dialog with the addition of Replace and Cancel buttons.
The General > Workspace > Local History preference page (see Figure 1-51) determines how much information is stored in local history. You can control how many days worth of changes are maintained, how many unique changes per file are maintained, and how large the entire local history is allowed to grow.
Figure 1-51. Local History preference page.
Many former VisualAge for Java users loved the ability of that IDE to revert to any prior version of any method or class. The Eclipse local history feature provides a way to emulate that behavior on a local scale. There is no reason (other than disk space) to keep the Eclipse local history settings at the low values to which they default. Increasing the Days to keep files setting to 365, the Entries per file to 10,000, and the Maximum file size (MB) field to 100 will allow you to easily track an entire year of changes.
You can change which editor is assigned to a specific file type using the General > Editors > File Associations preference page (see Figure 1-52). To change the editor, select the file type in the File types list, select the desired editor type in the Associated editors list, and click the Default button. If the desired editor type is not shown, use the File types > Add button to add it to the list.
Figure 1-52. File Associations preference page.
To add an editor association for a file type not listed in the File types list, click the File types > Add button to reveal the New File Type dialog, as shown in Figure 1-53. For example, to add an editor for HTML files, enter "*.html" into the File type field and click the OK button.
Figure 1-53. New File Type dialog.
Once the new file type has been added, an editor must be assigned to it. Click the Associated editors > Add button to open the Editor Selection dialog. By default, the various built-in editor types will be shown in the editor list.
To see a list of available external editors, select the External Programs radio button (see Figure 1-54). If you have an HTML editor (such as Microsoft FrontPage) installed in your system, select it from the list and click the OK button. That editor will be added to the Associated editors list and automatically made the default (assuming that no other default was in place).
If you routinely edit XML files, the XMLBuddy plug-in, from www.xmlbuddy.com, is one of several XML editors integrated into Eclipse (see Appendix A). The XMLBuddy editor provides user-configurable syntax highlighting, Document Type Definition- (DTD-) driven code assist, XML validation, and many other features.