Hey all,

In my posting I often post some Eclipse trick or two to illustrate a point.  Eclipse is a very powerful IDE that is based on a plugins architecture.  Netbeans is an IDE that takes a fairly similar approach but calls their plugins "modules".  The main differences (aside from perhaps some functionality) is that Netbeans ships with a default GUI editor, which you must install as a plugin for Eclipse (the Visual Editor).  Also, Eclipse is almost certainly faster than Netbeans on any platform it supports, due to its SWT architecture instead of the straight Swing approach Netbeans has.  If you're used to Netbeans, you may already know how to do all the things I am going to cover in this tutorial.  However, you may find some things in this tutorial that you cannot do in Netbeans, I wouldn't know, I've never used Netbeans, I only know of its differences via the internet.  You can find out more about Eclipse and download and install it via http://www.eclipse.org.

The tips and tricks here are based on Eclipse's default shortcut configurations.  If you have configured this, chances are the shortcuts may not work for you.

Eclipse is by default in the Java mode (perspective, in Eclipse parlance).  The Java perspective allows for the quick and easy editing of Java code.  How easy?  Very easy.

Start by making a new Java project.  Select File->New->Java Project.  The wizard appears.  Name it whatever you want and select finish.  You will see a src folder for your source files.

However, placing folders in the src folder would use the default package.  Thankfully, there are two ways to make a package: right click and select New Package, or use the New Class Wizard.

The New Class Wizard is a great feature of Eclipse.  This example will illustrate how to make a new Comparator.

Right click the src folder and select New->Class.  The new class wizard pops up.  Enter IntegerComparator as the class name, enter test for the Package name, and (optional) hit Generate Comments.  Next, hit the "Add" button to add an interface.  Scrolling through the interfaces might take forever, so just type in Comp.  Comparator can be fully spelled out this way, but it is easier to just click it in the list once it is added.  Unless you unchecked it, the box "Inherited Abstract Methods" should be added.  Now press finish.  You should see the package test be created, and your new class is displayed on the screen, ready to be implemented.  The inherited abstract method from the comparator class has a stub generated that will allow the class to be compiled, but of course it does not actually perform any logic at this point.

This tutorial will be short, and future tutorials will also probably be pretty short.  The remainder of the tutorial will teach you:
JavaBeans:
How to generate constructors
How to generate getters and setters
How to get rid of that damned serializable uid warning

Navigation:
Type Hierarchy/Quick Type Hierarchy
References/Read/Write access
Outline/Inherited outline

Refactoring:
How to encapsulate a field
How to rename classes, methods and variables
How to extract an interface from an implementation class.

JavaBeans:
A JavaBean is simply a class in Java that follows specific guidelines.  Although some of its guidelines are somewhat obscure (many times you will build JavaBeans without regards to event listening), the essentials for a JavaBean are (blatently copied from Wikipedia):

For more about JavaBeans, please see the Wikipedia article http://en.wikipedia.org/wiki/JavaBean

Although having a JavaBean be Serializable is ignored sometimes, it is required in certain circumstances and is included in this tutorial just so you can see the warning that Eclipse is quite good at fixing.

When programming, using JavaBean conventions not only makes your code look great, but it enforces encapsulation, allows for reflective instantiations of your class, and allows other coders that know the conventions be able to access your code immediately.

So, the first thing to do, naturally, is to provide a default constructor.  Although Java will provide a default constructor if no constructor is specified, actually specifying a default constructor will allow the class to be considered a JavaBean (without an explicit default constructor, although it can be handled like a JavaBean, the class is not actually a JavaBean).

A default constructor is simple to add.  Click before the stubbed compareTo method and add a couple of lines of whitespace for readability (it's not good to scrunch methods together, whitespace makes class files much more readable, and even if the class becomes a little longer because of it, Eclipse has certain tools (see the Navigaton section) to enable quickly jumping to certain methods irregardless of the whitespace in the file).

Press Control (hereby referred to as CTRL) and then space.  A list of options should pop up on the screen.  Start typing Integ and the IntegerComparator default constructor should pop up as the option to use.  Press enter and the IntegerComparator default constructor is now created.

Simple, huh?

CTRL+SPACE is the default shortcut for autocompletion with Eclipse.  It is used all over the place, and you should always check it first for help options.

However, although this comparator now has a constructor, it lacks a field.  We will make an example field now.

Add some more white space before the default constructor you have just created, and then type the following:

Eclipse will immediately pop up a warning in the Problems view that the field lastCompareResult is not used.  It is entirely correct.  This is a good thing if you have existing code and want to clean it up for maintenance.  However, ignore this warning for now.

This class needs two things for it to be a JavaBean: the inheritance of the Serializable interface and the specified convention for its field access.

Eclipse can help you with both of those.

Start with the field access.  Right click Eclipse and select the Source context menu option.  Now select "Generate Getters and Setters".

Click the checkbox on lastCompareResult to allow Eclipse to generate both a getter (a method to access the lastCompareResult value) and a setter (a method to modify the lastCompareResult value).

Then, click the drop down and have Eclipse place the generated methods after the last method.  Generally, the getters and setters of your Javabeans should go either before or after the actual logic of your class which uses them, as they are easily ignored if they are grouped in a certain place.  My personal preference is to put the properties at the top of the file and the getters and setters at the bottom of the file.

Press finish, and Eclipse has generated a getter and setter for the field lastCompareResult.  Notice that now the warning about accessing the field has gone away, because Eclipse does not know if code that you export your class to will use the PUBLIC methods you have provided or not, that they are there means the field is in use.

Finally, add a comma after the Comparator in the class declaration and start typing "Seri"  Press CTRL+SPACE, and you can then allow Eclipse to fill in the name of the Serializable interface (always pick java.io, not sun based classes).

Not only does CTRL+SPACE handle filling in the name of the class, but it also automatically imports the class for you.  Settings are available in "Organize Imports" to determine how many imports are used before packages are imported as "*", such as java.util.*.

However, though adding Serializable does make your class a glorified (if essentially useless, as it was an example) JavaBean, there is another warning added to your class:

"The serializable class IntegerComparator does not declare a static final serialVersionUID field of type long"

In order to fulfill the Serializable contract, your classes should declare a static final long serialVersionUID field (otherwise, this field will be automatically generated by the compiler/JRE, as you may see shortly).

There are two ways to easily fix this, and both involve Eclipse's "Quick Fix" feature.

The warning shows up in the Problems View, but it also shows up as a yellow (indicating warning, red indicates an error) light bulb next to the class name.  Clicking this light bulb shows certain options:

"Add default serial version ID"
"Add generated serial version ID".

Just for the heck of it, pick "Add generated serial version ID".  After a moment, Eclipse adds the serialVersionUID field with some strange numbers.  Congratulations, you've just used Eclipse's Quick Fix feature.

The strange numbers are what the compiler and/or JRE would have generated for the serializable id of your class.  However, this is often quite meaningless and doesn't track the version of your class at all.  So, delete it.  The problem will show up again.  This time select the "Add default serial version ID" option, and 1L will be your serializable id, which makes sense as it is the first version of your class.  Check the Serializable Javadoc for more information on this, but essentially to remove this warning in the future, just use Quick Fix to generate the default id.

Ok, the final thing in this part of the tutorial is how to generate a constructor based off your JavaBean's fields.

Right click on the editor, and select Source->Generate Constructor using Fields.  Click the lastCompareResult field and press OK.  Eclipse generates a constructor for your class that will allow you to initialize the lastCompareResult field directly.  Neat, huh?  You can also specify some options such as where to put it in the source code, etc.

Ok, now time for the Navigation section of the tutorial.

Navigation:
Type Hierarchy/Quick Type Hierarchy:
The Type Hierarchy is perhaps the most useful thing in Eclipse.  Give it a try.  Select the name of the class (IntegerComparator) and press F4 (you may also use the navigate menu to open the type hierarchy).

A view comes up with both the IntegerComparator class and its superclass, Object (duh).  Clicking on the other two buttons with green arrows will show the supertype hierarchy, showing the Comparator and Serializable interfaces as well as Object, and the subclasses of this object (none) respectively.  Click on the second button for the supertype hierarchy, and click Comparator.  Press F4 again to "focus" the type hierarchy on Comparator, and you can then use the appropriate buttons to explore Comparator's type hierarchy: which classes implement it, which interfaces extend it or which it extends, etc.  

If you had the GTGE library, for example, you would be able to easily see that the AdvanceCollisionGroup is a Comparator implementation.

The difference between a type hierarchy and a quick type hierarchy are that the quick type hierarchy is displayed as a popup menu similar to Javadocs in Eclipse.  To display the quick type hierarchy of IntegerComparator, highlight the class name in the editor and select Quick Type Hierarchy from right clicking and selecting the appropriate menu option.   Its shortcut is CTRL+T.  By itself, it isn't that great, and besides the greater speed, it isn't used very often compared to the type hierarchy.  However...it does give you a quick insight that the type hierarchy does not.

To illustrate this, override the toString method.  Remember CTRL+SPACE?  Just hit CTRL+SPACE where you wish to place the method, and type toStr.  The toString method should pop up almost immediately.  Hit enter to override it.  We're not going to do anything with it at this point, so the stub will suffice for the example.  Select the toString method and hit "Quick Type Hierarchy".  Now you can immediately see where this method came from!  Since it is Object, it isn't so impressive, but when you're dealing with a deeply nested type hierarchy, this can be invaluable.  It will also show you which of the current class' subclasses override this method, as well.  This is useful for creating a type hierarchy of your own using generic superclasses that provide method hooks to subclasses.

References/Read/Write access
Sometimes, you want to see where a particular type or field is referenced.  That's where the references search in Eclipse comes in handy.

To try it out, select the IntegerComparator name and select References->Workspace from right clicking with the context menu.  This would show you any class that referenced this class, where applicable.  But nothing shows up.  So try it on the field lastCompareResult.  You do find matches, because IntegerComparator references this field.  You can also track down the read and write access of a particular variable by selecting the search menu up above, and selecting either read or write access with a variable highlighted.  This will show you where protected or public fields are being used, or rather, not being used so that you can delete them safely

For methods, you can select them and select "Open Call Hierarchy" to see where they are called, and you can keep traversing up the stack until you find the class that called the method that called the method...that called the method.  It is also available by the context menu or navigate menu.

Outline:
I explained before how it was good to have whitespace separating code, instead of clumping it all together.  Not only does it look better and is more readable, but the white space does not impair navigation.  The Outline view is available in the Java perspective by opening it via the Window->Show View command.  It shows an outline of the current text editor, including methods, fields and static variables.  However, this Outline, while useful, is not the best outline to use when finding something.  Simply press CTRL+O (or right click and click Quick Outline) to open a searchable version of this Outline.  By default, this outline will show everything in the current class file.  You can filter what it displays by typing something.  For instance, typing "get" will show you all of the getters of the current class.  However, pressing CTRL+O again will show the *inherited* members of the class as well, so that every method and field accessible from the current class is displayed.

Refactoring:
Refactoring is the process of changing code without changing the actual logic of that code, i.e., changing the code's form but not its function.
Eclipse contains a bunch of refactoring tools, but I won't cover them all here.
The three I will focus on are encapsulating a field, how to rename classes, methods and variables
How to extract an interface from an implementation class.

Encapsulating a field:
Start by declaring a public variable:
public int thisShouldBePrivate;

Next, in the compare method, store 5 to this field:
thisShouldBePrivate = 5;

Highlight the name and choose Refactor->Encapsulate field from the context menu.
Keep the defaults and press OK.

Three things happened here.
One thing is that Eclipse generated getters and setters for the field thisShouldBePrivate.
The second thing is that Eclipse changed the access level of this field from public to private.
The third thing is that in the method compare, thisShouldBePrivate = 5 changed to setThisShouldBePrivate(5); because the default access options in the Encapsulate field refactoring box is to use the getters and setters instead of accessing the variable directly, which is usually the best option, as setters can be modified to do special things with its input, whereas an assignment is simply an assignment.

Fields should be encapsulated if you wish your classes to follow the JavaBean standard, although it is permissible to set the fields directly in the classes that define them (just note that if you do alter the state of the class from within the class, it is no longer thread-safe in certain contexts).

Renaming variables, fields and methods is easy.  In Eclipse 3.3 there is an option to do it inline in the code that is turned on by default, but 3.2 and earlier has a box pop up (and this box can be found if the inlining is disabled).  Simply highlight a variable, class name or method to rename and right click to select Refactor->Rename.  Type in the new name and press ok (or hit enter for the inlining in Eclipse 3.3).  The variable, class or method is now renamed NOT ONLY IN YOUR FILE, BUT ANYTHING IN THE WORKSPACE THAT REFERENCES IT.  RENAME IS POSSIBLY THE MOST POWERFUL REFACTORING OPTION IN ECLIPSE.

For instance, say you were rushed and you just named variables haphazardly, like num1 and num2.  Say that num1 was a weight, and num2 was a count.  With Eclipse, later you can rename those variables to count and weight all over the workspace with one operation, even if they occur a thousand times!

The shortcut for rename is ALT+SHIFT+R.

To practice, rename thisShouldBePrivate to privateField.

Oh wait...it is a JavaBean field with getters and setters.  This could be tricky.

However, Eclipse is smart enough to know that the getters and setters are associated with thisShouldBePrivate.  When you rename the field, it gives you the option of renaming the getters and setters as well!  How's that for convenience?!  (note that this is only accessible via the box, not the inline renaming of Eclipse 3.3.  If you use this option often (like I do), I recommend turning off the inline renaming to get this option).  The only thing that bugs me is that Eclipse leaves the original argument parameter name to the setter the same.  But you can rename that easily enough to match the new argument name, as well.

After checking both check boxes, you now have privateField, getPrivateField(), and setPrivateField(int).

Finally, a Java interface is a good polymorphism mechanism.  It specifies a contract that classes must implement, but classes are free to implement the contract any way they want.  If you knew Java well, you knew that

What you might not have known, is that Eclipse allows you to generate an interface from an implementation class.

Right click, select Refactor, and then select Extract Interface.  Name it ExampleInterface and select the getters and setters you generated.  When you press OK, the new interface is extracted.  Advanced options will make classes use this interface instead of an implementation class when you created, for example.

That's all the tips I have for now.  If anyone has any suggestions for more tips, let me know, ok?

This post was last modified: 29-05-2008 07:00 AM by MetroidFan2002.

The following tutorial teaches two more refactoring tricks with Eclipse.
Refactoring:
Pull up
Push down

Note that the class names provided here are FOR EXAMPLE ONLY and if you actually use these class names in a real application, YOU SHOULD BE SHOT.

Create a new class in your Java project called "SuperClass".  Then make two classes inheriting from "SuperClass", "SubClass" and "SubClass2".

*Tip: you can easily extend a class by right-clicking (or selecting File->New Class) from the Class icon of a class.  Note that this works for the ICON only, if you click the file, this will not work.

Place two methods into the "SubClass" class:

Yes, the methods do nothing.  But, as you'll see, that's not the point.

Finally, make a class that inherits from "SubClass": "SubSubClass" (again, these names are for example only, and if you actually use them you should be shot).

Ok.  Now the stage is set for refactoring.

Sometimes, you have a class that is extended by multiple classes.  You make a method in a subclass, but then when you think about it, perhaps it just needs to be slightly tweaked (by a protected method hook) or can be used as is in another class that inherits from the superclass, but it not related to the class that you define the method in.  "Pulling up" is the process of taking a method from a subclass and placing it into a superclass.

Highlight the allSuperClassClassesShouldHaveThis method to pull it up.  Right click, and select Refactor->Pull Up... (this is also available via the menu).  The only super class available is SuperClass, so you may either press finish, implementing the change immediately, or step through the dialogs using next to see the changes before they are performed.

After this action is done, go to the SubClass2 class and press Ctrl+O, then Ctrl+O again to display the outline with inherited members and methods.  The method allSuperClassClassesShouldHaveThis should now be accessible by the SubClass2 class.

"Pulling Down" a method is the exact opposite of "pulling up" a method.  Instead of making a hierarchy contain the method at the more generalized level, it is sometimes the case that it is better to push a method down to a more specific subclass that is the only class that needs it.

To try out push down, highlight the method "allSuperClassClassesShouldHaveThis" and right click to select Refactor->Push Down...  The process is the same as before: the only subclass available is SubSubClass, and you can just press finish, or press next to step through the process.  After the operation, "allSuperClassClassesShouldHaveThis" is no longer accessible from SubClass, it is only defined in the class SubSubClass.

Since SubClass no longer has any purpose, it should be deleted if it was an actual class, and SubSubClass could inherit directly from SuperClass.  But these are just example classes.

Note that you can push up and pull down other Java elements as well, such as fields.

Have fun pulling up and pushing down!

This post was last modified: 29-05-2008 07:30 AM by MetroidFan2002.

Did anyone find this useful? Should I write more? Does anyone want me to write about any specific task that is easy to do with Eclipse? I need feedback!

I was aware of all the features you've written about, except for the push up/down feature. I'll definately use that now.

Beyond that I don't have much more to say. Why don't you write about class version conflicts and how to solve them? I've encountered this a few times before, and it always gives me headaches for a couple minutes before I figure it out lol.

Class version conflicts? You mean as in serializable conflicts, or library version conflicts? Serializable conflicts are really their own thing, and as for library version conflicts, you just edit the build path to include the proper library. Problem is, you may not know which library is the proper library, so you wouldn't know to include it, so trial and error would be your best bet there