Easy ways to identify different branches when using Eclipse

When working on different branches in Eclipse, you’ll often find yourself wondering if you’re working in the right workspace for the right branch. This is especially an issue if you have multiple Eclipse instances open and you’re working on different branches of the same codebase, eg. dev, fix, release and feature branches.

There are a number of features in Eclipse that can help you distinguish which window belongs to which branch, including naming your workspace, naming perspectives and colouring your window.

Most features don’t show you the actual branch (ie. its name as it exists in the SCM) but they enable you to manually mark a workspace as belonging to a branch.

Run a single JUnit test method in Eclipse

Normally you would run all JUnit tests to ensure that changes haven’t broken any of the tests. But sometimes you want to focus on a single test method and only rerun that test, especially if running all tests is too slow or if you write a single (failing) test upfront.

For example, in the following code you might only want to run testMethod2():

public class SomeTest {
   @Test
   public void testMethod1() {...}

   @Test
   public void testMethod2() {...}
}

Eclipse provides a couple of ways to run individual test methods, one from within the editor itself and another from the JUnit view. It also has especially good keyboard support so you can run those tests without reaching for the mouse.

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.

Disable Eclipse formatting for certain sections of code only

In a previous tip, I showed how to automatically format code every time you save in Eclipse or how to manually format by pressing Ctrl+Shift+F. These work great most of the times but sometimes you want to exclude a certain block of code from formatting, often because the formatting turns out unreadable (ie. ugly) for that particular piece of code.

Eclipse allows you to disable formatting for a certain block or section of code by surrounding that code with formatter comments, known as Off/On tags. And you can also make generating those comments around a block of code extremely simple by creating a simple template.

Compare two workspace or external files in Eclipse

We all have our favourite diff tools for comparing files and it’s probably not Eclipse itself, unless you’re comparing version controlled files.

But sometimes you’ll want to compare two files from within Eclipse (whether they are in your workspace or external files) either because it’s quicker or you don’t have your own diff tool to hand.

Eclipse offers two ways of comparing files with each other. One of them is appropriately called Compare with Each Other. Although this is often the suggested way to compare files, it’s not easy to use and doesn’t work with external files. This post will focus on another Eclipse feature called Compare with Other Resource that makes things go a bit smoother and handles external files but it will also cover using Compare with Each Other.

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.

The easiest ways to navigate methods in a class using Eclipse keyboard shortcuts

Java classes can get big and hairy, making it difficult to find the method you’re looking for when browsing or editing a class. There is no specific order to where methods can be in a class and different developers have different preferences about where to put them.

You could use the mouse wheel and scroll ferociously until you eventually find the method or you could even use Page Down/Page Up on your keyboard. But these methods can be time-consuming and haphazard, especially when the class has lots of methods or they’re scattered in an arbitrary order.

Luckily, Eclipse has a number of fast and easy ways to help you navigate methods in a class, especially using the keyboard. I’ll discuss some of those keyboard shortcuts and also which ones to use when.

Generate, rename and delete getters/setters instantly in Eclipse

Despite the arguments and debates about getters and setters in Java, the fact is that they’re a reality and you have to work with them.

But managing getters and setters is a time-consuming effort. Creating a getter/setter for 5 fields in a class can take minutes, renaming one is error-prone and deleting one is just plain inconvenient.

There are options like Project Lombok (that implicitly creates getters/setters without the need to code them) and you could avoid getters/setters altogether by redesigning your classes.

But these options aren’t always available, so it’s a good thing Eclipse has some handy features for managing getters and setters. Combined with the ability to generate constructors based on fields, you can get the boilerplate code out of the way in seconds and get on with the real coding.

The fastest ways to open editors in Eclipse using the keyboard

Something you do a lot in Eclipse is open files such as classes, XML files and property files in editors. But using the mouse to hunt through the Package Explorer folder hierarchy takes a long time, especially if you forgot where the files are located. The problem gets worse the more projects and files you have in your workspace, so there must be a better way of opening editors.

Luckily, Eclipse has a number of ways to open editors easily using the keyboard. Couple these with oodles of keyboard shortcuts to navigate between editors once you’ve opened them, and you’ve got enough tools to stay away from the mouse and make coding go a lot faster. I’ll discuss some of the more efficient options and then give a summary of when to use which method.

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.