Eclipse Magazine

NEWS

COLUMNS

ONLINE ARTICLES

MAGAZINE

CONFERENCE

| Printer Friendly | Post Reply

MyEclipse: Getting the Most Out of the IDE for Java Development

By Adrian Colyer

Introduction

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 eight at present). 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 two or three eclipses open at the same time.

Therefore, the first practical question is how to know 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 each 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, for example, your home directory. Whenever you create a fresh workspace, use File->Import->Preferences and you’re good to go.

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 Figure 1 to see how the package explorer shows my core spring training workspace by default.

Fig. 1: Package Explorer showing projects

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 that shown in Figure 2.

Fig. 2: Package Explorer showing working sets

Sorting Out the Clutter Inside a Project
When looking at an individual project inside the package explorer, all the JAR files on the project build path show up by default. Most of the time I find these just get in the way. Have a look at Figure 3 to see how my spring development workspace looks with the JAR files showing.

Fig. 3: Jar files getting in the way

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 to see the maximum amount of code possible inside the Java editor window. I changed tactics a while ago. 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.

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. This can be a real pain, especially if you follow my suggestion of using a bigger font.

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 that shown in Figure 4.

Fig. 4: Exploiting Fast Views

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. 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.

If you have any views you may have on the right-hand side, just close them (for most people, this means the Outline View). Use the in-place views instead. 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.

I have a final tip on the subject of view arrangement. If you have a dual monitor setup (which is becoming very common in the client sites I visit), it is 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.

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; for example, ‘Alt-Shift-X,T’ to run a test case. 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:

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)
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).

There are some 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. See Table 1.

Table 1: Using the Arrow Keys

Other useful keys are listed in Table 2. (The standard cut/copy/paste keys are not included since I assume you are already familiar with these).

Table 2: Other useful key bindings

AspectJ Hints and Tips

Eclipse has great support for aspect-oriented programming (AOP) 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 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. 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 instantly visible in the AspectJ project (and vice versa). To get the best performance, you can 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

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. 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 to highlight the test or set of tests that you want to run and run them with Ctrl+R (if you’ve remapped that key binding, that is). 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 add the following in the ‘VM arguments’ box:

-javaagent:/lib/aspectjweaver.jar

Where 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, and such).

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 advices 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.

Figure 5: Visualization of search results

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. See Figure 6.

Figure 6: Controlling visualization of resources and markers

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 documentation 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!

[Adrian Colyer is the Chief Scientist at Interface21, where he contributes to the Spring, AspectJ, and AJDT open source projects and provides education, training, and consultancy to clients working with Spring and AspectJ. Adrian founded the AspectJ Development Tools project (AJDT) on Eclipse.org in 2003, a project that continues to lead the world in providing IDE support for aspectoriented programming (AOP). As leader of the AspectJ project, Adrian has overseen several releases of the compiler and designed and implemented many of the AspectJ 5 language extensions to support Java 5 features such as generics and annotations.]

Yatego Shopping with more than 4000 Shops and with over 1.8 Mio Products. Branchenbuch and over 500.000 Bücher. Inspiration with Themeworld and Technic. A mobilephone- and Handy Shop with Nokia Handy, Motorola Handy and Sony Handy. With our Bestseller easily find Schuhe, Jeans, Kinderschuhe or a Digitalkamera, perhaps a Canon Digitalkamera. More Bestseller: Modellbahn, Diddl and Poker. Find Schmuck or Silberschmuck as easy as an Apple Ipod, Weber Grill or an Akkuschrauber.

About Us | Advertise | Contact | Feedback | Publisher