In Germany they have an entire magazine devoted to Eclipse, called (imaginatively ;) "Eclipse Magazin"". I don't speak (or read) German, but I have to say the content always looks really good, and they've had some excellent coverage of AspectJ and AJDT in past issues. The magazine has a guest column, "MyEclipse" in which various users of Eclipse describe their favourite hints and tips for working with the IDE.
It was my turn to write the column this month.
I have to say, I enjoyed writing the piece more than I thought I would - amongst other things it made we really think about how I actually do use Eclipse, and whether I'm using it as effectively as possible. The original column can be found here. With permission, I'm making an English translation (strictly, the English original!) available here for those that don't read German. If you have any favourite Eclipse tips that I don't know about, please do let me know!
I’ve seen a lot of different people using Eclipse over the last few years. Nearly every one of them was using Eclipse pretty much in its default configuration. My Eclipse looks quite different to that, and in this article I’ll walk you through a collection of hints and tips for getting the most out of the IDE for Java development.
I’ll show you how to get organized when working with multiple workspaces, multiple projects, and lots of jar files. I’ll show you how to configure the IDE to help you write better code, and how to organize the Java perspective for maximum efficiency. As you might expect, I’ll also give you a couple of hints and tips for working with AspectJ!
Getting Organized
Using multiple workspaces
I tend to have multiple workspaces on the go at any one time (about 8 at present having just done a quick check). I use different workspaces for each major project (or version of a project) that I’m working with. For example, right now I’ve got workspaces for AspectJ 1.5.1 development, the AspectJ 1.5.0 release branch, Spring development, a couple of demonstration workspaces I use when giving talks, a workspace I use when giving training courses, and so on. It’s not uncommon for me to have 2 or 3 eclipses open at the same time.
The first practical question becomes knowing which eclipse is which when looking at the task bar or selecting between open windows using Alt-Tab. I always launch eclipse from the command-line using a script. Passing the “-showlocation” flag adds the workspace location to the windows title bar so that you can easily see which window is for which workspace. I normally start Eclipse with a little extra memory too (I find it works a little snappier that way). A good default for launching Eclipse if you’re working with sizeable projects would be something like this:
eclipse.exe –showlocation –vmargs –Xmx512m > /dev/null 2>&1
(I use cygwin, and I find that Eclipse tends to dump nonsense to the console that I don’t want to see, hence the redirect).
Another problem with using multiple workspaces is keeping your preferences and settings up to date across all of them. There is no need to configure each workspace individually every time you create a new one! Get one workspace set up exactly how you like it, and then select File -> Export -> Preferences. This will create a file that contains all of your preferences settings that you can keep in (e.g.) your home directory. Whenever you create a fresh workspace, use File -> Import -> Preferences and you’re good to go.
(By the way, if you're adding plugins to the base eclipse set, see Colin Sampaleanu's excellent blog entry on how best to manage that).
Coping with lots of projects inside a workspace:
It’s also not uncommon for me to have a lot of projects inside a workspace (one project per module). This is where working sets can make a big difference. Take a look at how the package explorer shows my core spring training workspace by default:
It’s just a jumbled mess of projects. Working sets to the rescue! From the drop down menu at the top right-hand corner of the Package Explorer view click on “Select Working Sets…”. From here you can define logical groupings of projects. With your groupings defined, select “Show -> Working Sets” from the drop-down menu. Now the Package Explorer will look something like this:
Much better!
Sorting out the clutter inside a project:
When looking at an individual project inside the package explorer, all of the jar files on the project build path show up by default. Most of the time I find these just get in the way. Here’s how my spring development workspace looks with the jar files showing:
The list of jars goes on even further, and worse, there are additional folders that I do care about at the end of the list. Select “Filters…” from the Package Explorer drop-down menu and define a new name filter matching “*.jar”. This will hide all of these jars from view making it much easier to find what you really want.
Organizing jar files:
On the subject of jar files, if you have common groups of jar files it can be very effective to define them as “User Libraries” that can be named and added to a build path as a unit. You’ll find the settings page to define user libraries under “Windows -> Preferences…” and then select Java -> Build Path -> User Libraries.
Sharing projects with others:
To make projects easy to share with others (for example, checking into a shared CVS repository) make the maximum use of variables. Right next to the option to define User Libraries, you’ll find the option to define Classpath Variables. When adding an external library to a build path of a shared project, always define a classpath variable that points to the containing directory on your local machine (or just the jar file itself). Then you “extend” the variable when defining a build path entry. This way each user can define the variable appropriately for their own local environment, but the project settings can still be shared in the repository.
Using Eclipse for Java Development
Helping Eclipse to help you write better code:
I used to use a small editor font in order to see the maximum amount of code possible inside the Java editor window. A while ago I changed tactics. Now I use a larger font than normal – 14 pt bold. As a consequence, I can see a lot less code in the editor at a time. This helps me write better code.
Let me explain.
It’s natural to want to see a whole method in one go. Seeing less code on the screen at a time has the subtle effect of making me write shorter, clearer methods. It’s also easier to sit back and reflect on code, and easier to pair program and work with others. Give it a try and see if it works for you too.
Organising the Java Perspective:
It used to be that I was never satisfied with the width I’d set for the Package Explorer and JUnit views. Too narrow and I couldn’t see the package and type names properly, or the stack traces in a test failure. Too wide and the editor window would get crushed between the Package Explorer on the left, and the Outline View on the right. Especially if you follow my suggestion of using a bigger font this can be a real pain.
I found the answer in a combination of fast views and in-place views. Now my eclipse dedicates as much real estate as possible to the source code. I have no views on the right-hand side, and no views on the left-hand side. The views I typically work with are the JUnit View, Type Hierarchy View, Package Explorer, and Javadoc View. Open these views, right-click in the title bar, and select “Fast View”. By default fast views dock at the bottom of the screen, but it’s not as convenient to move a mouse up and down to open them as it is to left-to-right. Select the fast view bar and choose “Dock on… left”. You have now reclaimed all of the space on the left-hand side that these views used to take, and your perspective should look something like this:
Another hidden benefit of this mode is that you can make the views wider than they were before, so that you can see the content properly (or even better for e.g. JUnit and Search, set the orientation to "horizontal" from the context menu). You can also set the widths of each view individually (JUnit wider than the Package Explorer for example, which is a significant improvement). If you don’t like having to move the mouse across to open a view, I’ll discuss a solution to that in a moment.
Any views you may have on the right-hand side, just close them (for most people, this means the Outline View). Instead use the in-place views. Ctrl-O opens an in-place Outline View (over the top of the editor). It’s actually better than the more usual docked view because it supports type ahead to quickly find the member you are looking for. Along with Ctrl-O, you also need to learn Ctrl-T which opens an in-place “quick” type hierarchy. This is a really easy way to see all implementers of an interface for example.
A final tip on the subject of view arrangement. If you have a dual monitor setup (becoming very common in the client sites I visit) it is quite nice to undock the Javadoc view completely – just grab it and drag it right outside of your Eclipse window and onto your second monitor screen. Now you’ll have the javadoc permanently open as a reference tool while you work. (Yes, you can undock views in Eclipse now, a lot of people seem not to know that).
On the subject of key bindings, you can significantly improve your productivity in Eclipse by learning some of the basic keyboard short cuts for common tasks (and indeed, for some things in the Java editor that aren’t available from the menus at all). However it’s also true that some of the default bindings for common tasks are absurd: “Alt-Shift-X,T” to run a test case for example – one of the tasks you’ll be doing very frequently I trust. When using fast views, I also find it convenient to add key bindings to open the Package Explorer and JUnit views quickly without having to move the mouse at all.
I make the following changes to the default key bindings:
| Key combination | Result |
|---|
| Ctrl-P | Open the Package Explorer (normally bound to print, but I hardly ever print from Eclipse, and will happily use the menu for that) |
| Ctrl-R | Run as a test case. (normally bound to run-to-line in the debugger). Running tests should be a simple key-stroke away at any time. |
| Ctrl-J | Open the JUnit View (normally bound to incremental search) |
| Ctrl-I | Incremental search |
| Ctrl-G | Generate getter/setter |
| Ctrl-B | Toggle breakpoint |
Now that you have Ctrl-R to run tests, it’s worth knowing that you can use this shortcut from within the editor when editing a test case, when a package is selected (to run all the tests in the package), when a source folder is selected (to run all the tests under the source folder), and when a project is selected (to run all the tests in the project).
Here are some of the other key shortcuts that I find amongst the most useful:
You’re already familiar with using the arrow keys (left,right,up,down) to move around within the editor. Using the arrow keys in combination with Alt, Shift, and Ctrl put a whole new set of capabilities at your fingertips:
| Key combination | Result |
|---|
| Arrow keys | Move cursor point in editor |
| Shift + arrow keys | Increase/decrease selection in editor |
| Alt+Shift + left,right | Select previous syntactic element / next syntactic element |
| Alt+Shift + up, down | Select enclosing element / restore last selection |
| Ctrl+Shift+left,right | Select next word / previous word |
| Ctrl + left,right | Move left / right by one word |
| Ctrl + up,down | Scroll up / down by one line |
| Ctrl+Shift+up,down | Go to previous member / go to next member |
| Alt + left, right | Go forward and backward in history (really useful if you’ve been following links exploring the code) |
| Alt+up,down | Hidden treasure! Move the current line or selected lines up and down |
| Ctrl+Alt+up,down | Duplicate line above / below |
Other useful keys (standard cut/copy/paste etc. not included as I assume you are already familiar with these):
| Key combination | Result |
|---|
| Ctrl+O | In-place outline view |
| Ctrl+T | In-place quick type hierarchy |
| Ctrl+M | Maximize/restore current window/view |
| Ctrl+D | Delete line |
| Ctrl+Shift+delete | Delete to end of line |
| Shift+Enter | Insert new line below |
| Alt+Shift+R | Rename |
| Alt+Shift+T | Quick refactoring menu |
| F3 | Open declaration |
| F4 | Open in type hierarchy |
| F11 | Debug last launched |
| Ctrl+F11 | Run last launched |
| Ctrl+Shift+T | Open type |
| Ctrl+Shift+R | Open resource |
| Ctrl+Shift+G | Search for references in workspace |
| Ctrl+F6 | In-place editor selection |
| Ctrl+F7 | In-place view selection |
| Ctrl+F8 | In-place perspective selection |
| F12 | Activate editor (useful if you’re following my suggestion of using fast views :- F21 will dismiss the fast view and return you to the editor) |
AspectJ hints and tips
Eclipse has great support for aspect-oriented programming with AspectJ through the AJDT plugins. In this section I’ll show you how to set up projects using linked source folders, how to run JUnit tests with an aspect library using load-time weaving, and some things you can do with the Visualizer that you may not realise. See the AJDT site on Eclipse.org for a tutorial on using AJDT – this section just contains a few less-well-known pointers.
Before we start, if you’re trying out using fast views and closing all the views on the right-hand side, one of things you’ll be missing is the cross-references view from AJDT (with all of the advises and advised-by relationship information). You can either dock this at the bottom (alongside the console for example), or use the in-place quick cross references view (not a lot of people know about that!). It has a not-very-useful default key binding of Alt-Shift+P, I remap it to Ctrl+U (not many letters left to choose from!). Now just press Ctrl+U anywhere in the editor and get a pop-up view of the cross-references for the selected element. Press it again to get cross-references for the whole file. Perfect!
Linked source folders:
Linked source folders can be a great way to experiment with aspects on a project without touching the main (Java) project at all. Create an AspectJ project alongside the Java project that you want to work with. Put all of your aspects into the “src” folder of the AspectJ project. Now, inside the AspectJ project open the project properties (Alt+Enter, since we’re trying to wean you off the mouse!) and go to the Java Builder page, and then the “Source” tab. Click on “add folder” to create a new source folder, and then the “Create new folder…” button. Here you’ll see an “Advanced” button. If you press this, you’ll get the option to create a folder that is actually a symbolic link to another location. Use this technique to create source folders inside the AspectJ project that are symbolic links to the source folders inside the Java project you want to work with.
Now whenever you build the AspectJ project, you will get (in the bin directory of the AspectJ project) a woven version of the project files. You will also see any warnings or errors arising from your use of declare warning / declare error in this project. The “donor” Java project remains completely unaffected by this exercise. Any changes to the source files in the Java project are of course instantly visible in the AspectJ project (and vice versa). To get the best performance, you can now turn off incremental building for the AspectJ project (Project menu -> build automatically) and just build that project on demand using the AspectJ build button in the taskbar.
Load-time weaving
(See my entry on using an aspect libraryfor a more in-depth treatment of this)
If you’re using an aspect library (such as spring-aspects.jar that ships with Spring 2.0) it is very convenient during development to use “load-time weaving”. Load-time weaving is the name given to weaving your application classes at runtime as they are loaded into the virtual machine. In this way there is no need to convert your project to an AspectJ project, or to do anything special at all other than put the aspect library on your build path.
Say you have some integration tests that you kick off via JUnit, and that rely on the behaviour contributed by the aspects in order to pass. For example, you’re using @Configurable to dependency inject domain objects. With the needed library on the build path, create a launch profile for the test run. The easiest way to create a launch profile is just to highlight the test or set of tests that you want to run and run them with Ctrl+R (if you’ve followed my advice and remapped that key binding). This run will fail, because you haven’t activated load-time weaving yet. Now select “run…” from the launch menu and you’ll see the launch profile that was created for the tests you just ran. Click on the arguments tab, and in the “VM arguments” box add the following:
-javaagent:aspectj-install-dir/lib/aspectjweaver.jar
Where aspectj-install-dir is the directory where you installed AspectJ (it’s best to download the standalone compiler and associated tools from www.eclipse.org/aspectj when using load-time weaving, ant building etc..).
Now you can rerun the tests and you’ll find that AspectJ picks up and uses the aspect libraries that you have on your classpath. It really is as simple as that.
Visualizer:
One of the tools that you get when you install AspectJ is the Visualizer. In fact, you get a whole “Aspect Visualisation” perspective which is the best way to use the visualiser. By default, the visualiser shows you cross-cutting information such as advises and advised by relationships. The visualizer plugin actually provides a generic capability that is not tied to AspectJ though. Open the visualizer perspective, and from the drop-down menu of the main visualizer view select “preferences”. Here you can choose the data provider that the visualizer will use to display information. By default it uses the AspectJ provider as I said. If you change to the “JDT Search Results Provider” you can use the view to visualize the results of the current search (all the matches, and where they are in the project).
The following image shows the results of searching for references to “InitializingBean” in Spring. Just as with the advice visualization, you can navigate from the visualization to the source code locations simply by clicking on the bars.
If you select “Resource and Markers Provider” you can see where all of your breakpoints, Task markers, warnings and errors are. Clicking on the options in the visualizer menu enables you to choose the subset of these that you are interested in at the time:
And finally
If you haven’t done so already, you should check out the Mylar plugin for Eclipse (developed by one of the AspectJ team, Mik Kersten) (see www.eclipse.org/mylar, and then go to the getting started page and watch the flash videos there). Especially if you’re working with bugzilla, Mylar is fantastic. Mylar deserves an article all of its own so I won’t attempt to describe it here – just go and try it out for yourself, you’ll be glad you did!
Here is the use of each button for debug purpose. 
Step Into: To go inside a Method.
Step Over: To bypass the next line of code.
Step Return : To come out of the current execution of method to original from where you stepped in.
Resume: to resume from the current breakpoint.
