Essential tools to manage import statements in Eclipse

It’s a big hassle to manually organise package import statements so it’s important to know what tools are available so your IDE can handle imports as quickly and quietly as possible.

Adding import statements for missing references and removing unused imports can take ages and the list of imports can get very long and hard to manage. As an example, the import statements below can consist of static/normal imports and wildcard/class imports:

// The list of imports can get really long...
import static org.junit.Assert.assertEquals; // Static imports
import java.util.List;
import java.util.ArrayList;
import org.apache.commons.lang.*; // Wildcard; unused so should be removed
...
public class MyTest {
   @Test
   public void testSomething() throws Exception {
      List<String> messages = new ArrayList<String>();
      assertEquals(1, 1);
   }
}

To make life easier, Eclipse has a heap of features that automatically manage import statements, including organising them when you save or when you press a keyboard shortcut. It can even deal with static imports. This tip covers some of these features, starting with the absolute essentials that save loads of time and moving on to more optional features that will depend on your environment and tastes.

Skip over certain classes when using Step Into in Eclipse’s debugger

Whenever I use the Step Into feature (F5) in Eclipse’s debugger, I’m mainly interested in stepping through code in my own classes, not the ones from external libraries or even Java classes.

For example, there’s almost no reason to ever want to step into Spring’s code or proxy classes (other than to learn more about them or maybe debug a potential bug in Spring). And normally I’m not interested in Java util classes (eg. ArrayList). This also goes for Hibernate, Apache Commons, Google and many other external libraries.

Fortunately, Eclipse makes it easy to specify which classes to skip by allowing step filters. This makes it easier to focus on your own code and also keeps your editor area clean since Eclipse won’t be opening classes in separate editors all the time.

Configure those annoying tooltips in Eclipse to only popup on request

Whenever you hover over any piece of code in Eclipse, it pops up a tooltip that displays more information about the item, such as its declaration, variable values or Javadoc information, as in the example below.

Although useful at times, this becomes extremely annoying after a while, especially when you’re using your mouse to browse some code. Popup after popup of unwanted information keeps obscuring your view of the code, leading to some lengthy expletives and big productivity loss. It’s useful information, but not every time all the time, almost like your car’s GPS giving you directions to 10 different places at once while you’re still parked in the driveway.

Luckily there is a way to alleviate the problem and all it takes is changing some preferences in Eclipse. We don’t want to completely disable tooltips (they can be useful), so I’ll show you how to tell Eclipse to bring up the tooltips only when you request them.

Get warnings about unused method arguments from Eclipse to keep code clean

Unused variables and methods should alway be unwelcome. Removing them keeps the code cleaner and easier to read. Now, by default Eclipse warns you about unused private variables and methods, but it doesn’t warn you (by default) about unused method arguments.

But there is a compiler setting in Eclipse that can warn you when you don’t use an argument in a method. You can even handle arguments on inherited methods, especially useful when using 3rd party libraries.

Share Eclipse perspective layouts across multiple workspaces

Once you’ve configured Eclipse preferences to your heart’s content, you’ll often want to share those preferences across multiple workspaces. Now normally you can go to File > Export > General > Preferences to save your preferences to a properties file which you can then import into the other workspace. This will share settings such as your customised keyboard shortcuts, formatting, repository settings, etc.

But, for some reason, Eclipse doesn’t save perspective/window layouts, such as which views are open and where they are placed in the perspective. So you’ll find yourself spending another half hour configuring the window to the way you like it. After the 3rd workspace you need to create, this becomes frustrating and just wastes time.

Fortunately there are ways to save and restore these settings automatically. The first is to save the perspective into the preferences (currently only works in Eclipse 3, to be fixed in Eclipse 4) and the other is to use Eclipse’s Copy Settings feature when opening the other workspace. I prefer the first option, but I’ll mention the second option and when to use the one over the other.

Automatically place a semicolon at the end of Java statements in Eclipse

We all know that Java statements are terminated by a semicolon (;), but they’re a bit of a pain to add to the end of a line. One way would be to press End (to move to the end of the line) then press semicolon, but this is tedious. Because this is something that you do often it’s worth learning how to do this faster.

It’s a good thing Eclipse can automatically put the semicolon at the end of the line, no matter where you are in the statement. It’s as easy as setting one preference and there’s a bonus preference for adding braces to the correct position as well. For something so small, it saves a lot of time.

So in the example below, if you imagine that your cursor is placed after the word blue since you were editing the string. Pressing semicolon will cause Eclipse to place the semicolon after the closing bracket at the end. Nice.

System.out.println("The house is blue")

How to manage keyboard shortcuts in Eclipse and why you should

When I use Eclipse I try and use shortcuts all the time. They really make me work faster and give me time to focus on getting the code out rather than slowing down to invoke IDE commands with the mouse.

Because people work differently and on different things, it’s important to manage keyboard shortcuts to suit the way you work. So it’s good that Eclipse makes it really easy to change shortcuts and also to view shortcuts for the commands you use a lot.

I’ll discuss how to change keyboard shortcuts, how to avoid conflicts with existing ones, why it’s a good thing to manage shortcuts and then end off with some examples of common shortcuts that you should add to you arsenal.

Generate static imports in Eclipse on autocomplete for JUnit Assert, StringUtils and others

Eclipse normally adds import statements for you when you autocomplete a type, press Ctrl+Shift+O or organise imports when you save. However, by default it doesn’t do the same for static imports, something you’ll miss when using classes like JUnit’s Assert and Apache Commons’ StringUtils. This means having to add import statements manually, which takes unnecessary time.

So, in the code below, I want to be able to autocomplete assertEquals (line 7) and have Eclipse add a static import for org.junit.Assert.assertEquals (line 1).

import static org.junit.Assert.assertEquals;
...
public class MyTest {
   @Test
   public void testSomething() throws Exception {
      assertEquals(1, 1);
   }

Now, the good news is that there is a way to automatically add static imports when you use autocomplete. It’s done via a preference that tells Eclipse which static classes you want to include for Content Assist (autocomplete). I show you how to do this below.

The bad news is that there doesn’t seem to be a way to tell the Organise Imports command to add static imports. However, a working autocomplete should already cater for 90% of your coding needs, so the bad news isn’t that bad.

Always run/debug the last launched class instead of the selected one in Eclipse

I previously mentioned shortcuts to run/debug a class as a Java app/JUnit test. But have you ever tried to rerun the last application you launched in Eclipse using F11 or the toolbar, only to find out it’s running the currently active class or selection in Package Explorer? Well, that’s because Eclipse’s default is to run the selected resource or active editor if it’s launchable (eg. if it has a main method or is a JUnit test).

Luckily, there is a preference you can change to force Eclipse to always run the last application you launched. So now you can avoid the confusion and rest assured that it’ll do what you want it to do.

Automatically format and cleanup code every time you save

Eclipse has a wonderful feature that formats according to your coding standards. It handles things like indentation, where curly braces are placed, if blank lines should occur between field declaration and hundreds of other options.

However, to invoke this formatting, you have to tell Eclipse to do this every time you’ve edited the code. You can do this using Ctrl+Shift+F but (1) you have to do that every time and (2) you have to remember to do it in the first place (and we all know how good developers are at remembering things).

Eclipse sports a feature called Save Actions that makes formatting code easy. With this feature enabled, every time you save the file, Eclipse formats the code to your formatting preferences and does some cleanup of the code (eg. remove unused imports). All done automatically and for free.