Editor's note: In part one of this two-part series of excerpts from Eclipse, author Steve Holzner provided examples of how Eclipse makes it easier to create Java code from scratch. Continuing in that vein, in this week's concluding excerpt Steve covers creating Javadocs, refactoring, adding certain skills to your Eclipse toolbox, and customizing the development environment.
|
Related Reading |
Eclipse also makes it easy to develop Javadoc documentation, the standard Java documentation that accompanies Java programs. You'll notice that in the code it generates, Eclipse inserts some text for Javadoc, as you see in Ch02_05.java:
package org.eclipsebook.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
.
.
.If you want to enter your own Javadoc, code assist helps you here, too; for
example, if you enter @param and invoke code assist with Ctrl+Space,
code assist will list the parameters a method takes. Typing @exception and using code assist will list the exceptions a method throws, and so on. Typing
@ in a comment and pausing will make code assist display the Javadoc
possibilities, like @author, @deprecated, and so on.
To generate Javadoc from your code, select the Project→ Generate Javadoc
item, opening the Generate Javadoc dialog, which lets you select the project
for which you want to create Javadocs. To browse a project's Javadocs, select
the Navigate→ Open External Javadoc menu item. For example, you can see
the generated Javadoc for the Ch02_05 project in Figure 2-19.
Figure 2-19. Browsing Javadoc
One of the major advantages of using a good Java IDE like Eclipse is that it can let you rename and move Java elements around, and it will update all references to those items throughout your code automatically.
For example, take a look at the code in Example 2-6. Here, we've used code assist to create a new method to display a simple message, but we forgot to change the default name for the method that code assist supplied.
Example 2-6. The Ch02_06.java example
package org.eclipse.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch0206 {
public static void main(String[] args) {
name( );
}
public static void name( ) {
System.out.println("No worries.");
}
}This default name for the new method, name, is called in the main method, and it could be called from other locations in your code as well. How
can you change the name of this method and automatically update all calls to
it? Select name in the editor and then select the Refactor→ Rename menu item, opening the Rename Method dialog you see in Figure 2-20.
Figure 2-20. Refactoring a method
Enter the new name for the method, printer in this case, and click
OK. When you do, the name of this method and all references to it will be updated
throughout your code, including all code in the project, as you see here:
package org.eclipse.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch0206 {
public static void main(String[] args) {
printer( );
}
public static void printer( ) {
System.out.println("No worries.");
}
}We've also misnamed the class in this example—Ch0206, instead
of Ch02_06. To rename the class, select Ch0206 in
the editor and select the Refactor→ Rename menu item, opening the Rename
Type dialog you see in Figure 2-21. Enter the new name, Ch02_06,
and click OK to rename the class.
Figure 2-21. Refactoring a class
Clicking OK not only changes the name of the class in the code, it even changes the name of the class's file from Ch0206.java to Ch02_06.java, as you can see by checking the Package Explorer. Here's the new code:
package org.eclipse.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch02_06 {
public static void main(String[] args) {
printer( );
}
public static void printer( ) {
System.out.println("No worries.");
}
}In fact, we've unaccountably managed to misname the package as well when creating
this example—org.eclipse.ch02 instead of org.eclipsebook.ch02.
When you refactor it, the name is changed both in the Package Explorer and throughout
your code:
package org.eclipsebook.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch02_06 {
public static void main(String[] args) {
printer( );
}
public static void printer( ) {
System.out.println("No worries.");
}
}As you can see, it's easy to rename Java elements in your code—Eclipse will handle the details, making the changes throughout your code automatically.
TIP: If you simply type over a Java element in your code, no refactoring happens. You've got to explicitly refactor if you want those changes to echo throughout your code.
Refactoring works automatically across files as well. Say, for example, that
you want to move the printer method to another class, Ch02_06Helper.
To see how this works, create that new class now, which Eclipse will put in
its own file, Ch02_06Helper.java. Then select the method you want to
move, printer, by selecting the word "printer" in the declaration
of this method. Next, select the Refactor→ Move to open the dialog you
see in Figure 2-22. To move this method to the Ch02_06Helper class,
enter the fully qualified name of that class, org.eclipsebook.ch02.Ch02_06Helper,
in the dialog and click OK. This moves the printer method to the
Ch02_06Helper class like this:
package org.eclipsebook.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch02_06Helper {
public static void printer( ) {
System.out.println("No worries.");
}
}
Figure 2-22. Moving a method between classes
And the call to the printer method is automatically qualified
as Ch02_06Helper.printer back in the Ch02_06 class
in the main method:
package org.eclipsebook.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch02_06 {
public static void main(String[] args) {
Ch02_06Helper.printer( );
}
}You can also extract interfaces using refactoring. To see how this works, we'll
create an interface for the Ch02_06Helper class (this class has
the printer method in it). Convert printer from a
static to a standard method by deleting the keyword static in the
method declaration. Then select the name of the class, Ch02_06Helper,
in the editor and select Refactor→ Extract Interface to open the Extract
Interface dialog you see in Figure 2-23. Select the printer method
to add that method to the interface, and then enter the name of the new interface—Ch02_06HelperInterface—and
click OK.
Figure 2-23. Extracting an interface
Clicking OK creates a new file, Ch02_06HelperInterface.java, where the interface is declared:
package org.eclipsebook.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public interface Ch02_06HelperInterface {
public abstract void printer( );
}The original class is now declared to implement this new interface, Ch02_06HelperInterface:
package org.eclipsebook.ch02;
/**
* @author Steven Holzner
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Ch02_06Helper implements Ch02_06HelperInterface {
public void printer( ) {
System.out.println("No worries.");
}
}Besides renaming and moving elements and extracting interfaces, there are other operations you can perform with refactoring, such as converting anonymous classes to nested classes, changing a method's signature, and converting a local variable to a class field. For these and other options, take a look at the items available in the Refactor menu.
|
There are some additional skills that are good to know about. For example, if you highlight an item in the JDT editor, right-click it, and select Open Declaration, the declaration of that item will open. This is great for tracking down where and how methods and fields were created. Several of those are detailed in this section and all are worth adding to your Eclipse toolbox.
Another menu item in the JDT editor's context menu is the Open Type Hierarchy; when you select an item in the editor and select this menu item, that item's type hierarchy appears in the Java perspective's hierarchy view, as you see at left in Figure 2-24.
Figure 2-24. The hierarchy view
This view acts like an object browser. It lets you explore a type's Java complete
hierarchy, and double-clicking an item in this view opens its definition in
the editor. That's useful if, for example, you want to see all the members of
the System.out class—just highlight System.out in your code and open its hierarchy. You can also open this view by selecting
an item in the editor and selecting the Navigate→ Open Type Hierarchy item.
The hierarchy view is not dissimilar from the outline view, which you see at right in Figure 2-24. However, the outline view is designed to show an automatic hierarchy of your code rather than the hierarchy of items you specifically select. As you work in the JDT editor, the outline view is updated automatically to show the hierarchy of the current type you're working with.
There's even another entire perspective dedicated to letting you browse through projects in a Java-oriented way: the Java Browsing perspective. To open this perspective, select Window→ Open Perspective→ Java Browsing; you can see the results in Figure 2-25.
Figure 2-25. The Java browsing perspective
This perspective presents the information you see in the standard Java perspective in a new way, and it breaks type and member information into two new views (the Members view here is much like the Outline view in the standard Java perspective). As you'd expect, the views in this perspective are all coordinated—selecting an element in the Projects views makes its packages appear in the Packages view, for example. And selecting an item in the Members view makes that item appear in the editor, and so on.
Eclipse also has great facilities for searching through code in the Search menu. In fact, the main menu items in the Search menu, Search→ Search, Search→ File, Search→ Help, and Search→ Java, all open the Search dialog, although each item corresponds to a different tab in that dialog. Searching is particularly powerful in Eclipse—for example, not only can you search across multiple files, you can also search using wildcards.
The File Search tab in the Search dialog lets you search across multiple files.
For example, in Figure 2-26, we're searching for the word main through all .java files in the workspace. The scope of the search is
set with the radio buttons in the Scope box, and the default is to search all
matching files throughout the workspace (that is, all your projects that appear
in the Package Explorer). You can also restrict the search to a working set
(covered in a few pages) of projects. If you want to search only the current
project or just a restricted number of projects, you can select that project
or those projects in the Package Explorer, then open the Search dialog and select
the Selected Resources radio button in the Scope box.
Figure 2-26. Performing a file search
Clicking Search makes Eclipse search for matches to the text you've entered, and you can see the results in the Search Results view, which appears at the bottom in Figure 2-27. Double-clicking a match in the Search Results view opens the match in the JDT editor, as you can see in the figure, and both underlines the match and points to it with an arrow.
Figure 2-27. Viewing search results
You can also perform Java searches with the Java tab in the Search dialog. This lets you search for Java elements by kind—types, methods, packages, constructors, and fields—as you can see in Figure 2-28. You can also limit the search so that it only matches declarations or references.
Figure 2-28. Performing a Java search
Being able to search across files and classes is one of the big advantages
of using an IDE—if you've been doing Java development using a text editor
and javac, you'll find there's no comparison when you start using
the project management capabilities like these in Eclipse.
Our last topic in this chapter is all about customizing your development environment. Eclipse is easy to customize, starting from the most basic—you can move any view, editor, or toolbar around simply by dragging it.
TIP: If you don't like to work in an environment where things can move around with mouse movements by mistake, you can lock the toolbars with the Window→ Lock the Toolbars menu item. And if a perspective gets all scrambled by inadvertent mouse movements, use Window→ Reset Perspective to restore things.
You can also customize how Eclipse will generate code for you. For example, the default code generation style doesn't place opening curly braces on their own lines:
public void printer( ) {
System.out.println("No worries.");
}However, your programming style might be more like this, where each curly brace does get its own line:
public void printer( )
{
System.out.println("No worries.");
}You can customize this with the Windows→ Preferences item, opening the Preferences dialog you see in Figure 2-29. Select the Java→ Code Formatter item, which lets you specify options for code generation. Here, select the "Insert a new line before an opening brace" item, as you see in the figure; the sample code below will change to match.
Figure 2-29. Customizing code generation
Here's another way you can customize how Eclipse generates code. When you create a new file, this kind of comment is inserted automatically:
/*
* Created on Oct 17, 2003
*
* To change the template for this generated file go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/As this text says, you can change this with the Window→ Preferences item,
followed by the Java→ Code Generation→ Code and Comments item (the
> you see in the code is the HTML escaped version of >,
which is used so the resulting Javadoc can be opened in a browser; the comment
actually reads, "To change the template for this generated file go to Window → Preferences → Java → Code Generation → Code and Comments").
When you open the Preferences dialog and select the Java→ Code Generation→ Code and Comments→ Code→ New Java files item, as you see in Figure
2-30, you can edit the template Eclipse uses to generate this comment.
Figure 2-30. Configuring comment templates
You can even create new code assist items in Eclipse. For example, say you
want to create a shortcut for the code needed to print out the current date.
To do that, select Window→ Preferences, followed by the Java→ Editor→ Templates item. We'll create a new shortcut named ptd to print the date, as you see in the name box in Figure 2-31. In this case, the template System.out.println("$2004-06-16"); will be replaced by the code to
print out the date. Besides $2004-06-16, you can use other values,
such as ${cursor}, to indicate where to place the cursor after
the insertion has been performed (when you type ${, code assist
will display all the possible values you can use in code assist expressions).
Figure 2-31. Creating a code assist shortcut
Now when you type ptd in code, followed by Ctrl+Space, code assist
will enter the code needed to print out the current date, as you see in Figure
2-32. In fact, if you type p, followed by Ctrl+Space, code assist
will list all its options that begin with the letter "p"—including ptd.
Figure 2-32. Customizing code assist
Another way of customizing your development environment is to create working
sets. Working sets let you limit what appears in the Package Explorer.
For example, to create a working set consisting only of the projects Ch02_01 and Ch02_02, click the Package Explorer's pull-down menu (that's
the inverted black triangle at the top of this view) and select the Select Working
Set item, opening the Select Working Set dialog. To create a new working set,
click the New button and select the Java item in the Working Set Type box in
the New Working Set dialog. Then click the Next button. Now you can select the
projects for this working set, as you see in Figure 2-33. In this case, we'll
create a working set named 1And2Only and select only the Ch02_01 and Ch02_02 projects for this working set.
Figure 2-33. Creating a working set
Clicking Finish creates the new working set and opens the Select Working Set
dialog. Select the 1And2Only working set and click OK. When you
do, only the Ch02_01 and Ch02_02 projects appear in
the Package Explorer, as you see in Figure 2-34.
Figure 2-34. Using a working set
To restore all projects to the Package Explorer, select the Deselect Working Set item from the Package Explorer's pull-down menu.
In fact, you can customize entire perspectives as well. To do that, select the Window→ Customize menu item, opening the Customize Perspective dialog, as you see in Figure 2-35. You can use this dialog to customize menu items available for the current perspective; for example, you can specify what views the user can switch to with the Window→ Show View menu item, as you see in the figure.
Figure 2-35. Customizing a perspective
TIP: After you're done setting Eclipse preferences, you can export those preferences so others can use them as well. To do that, use the Import and Export buttons in the Window→ Preferences dialog.
And that completes our look at some of the extraordinary power that Eclipse places at your fingertips for Java development. In the next chapter, we're going to discuss testing and debugging your Java code.
Steve Holzner is the author of O'Reilly's upcoming Eclipse: A Java Developer's Guide.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.