As a Java dev, a lot of code implementation is done against interfaces. In Eclipse, F3 goes to the definition of an interface.

In previous versions of Eclipse (3.2/3.3/3.4 era), I would always install the implementors plugin which added Alt-F3 as an ‘open implementation’ shortcut.

In Eclipse 3.6, this functionality is now built-in. If you ctrl-click on a method, it pops up a dialog asking if you want to open the implementation or the definition.

If you goto preferences…keys, and filter by ‘open i’, there will be an open implementation option. Assign it to whatever key you want (I use Alt-F3 due to familiarity with Implementors). Now, if you press F3, it will continue to take you to the definition. Alt-F3 will now take you to the implementation. Open implementor works regardless of whether you’re in the interface definition, or on a caller of the method.

Just read about this feature here. Basically, allows you to use pattern matching to shorten the name of packages that appears in the package explorer.

There are 2 options here. The first is to compress the package names.

As per the dialog, if you type some text (other than a number) as the pattern, each level will display that text instead.

So, given org.eclipse.jdt, and entering text a_, it would display as a_a_jdt.

If you put a number in the list, it will show that many leading characters.

So, if you put 1, you would see oejdt. If you put 1., you would see o.e.jdt.

The second feature is to abbreviate package names. In the dialog, enter the portion you would like to substitute a shorter name for, and provide the replacement text.

e.g. org.eclipse=oe, and you would see oe.jdt.

The 2 rules can be combined, so if you had the package org.eclipse.jdt.compiler and had a pattern of 1., and an abbreviation as above, you would see oe.j.compiler.

If you use AOP, hibernate and various other projects, and you’re debugging in Eclipse, I’m sure you’ve encountered this scenario.

You hit F5 (step-into) and end up in an interceptor, which leads to another and another, and eventually you get to the line of code you actually want. Of course, I could open the file I want and do Ctrl-R (run to here), but if I forget… plus it’s extra work.

The other place is in a method, and wanting to return. Press F7 (Step Return) and end up walking back through all the interception code.

Well, Eclipse has an ‘answer’ for this. They’re called Step Filters, and can be found in preferences, Java/Debug/Step Filtering. You will likely already see some entries here, but feel free to add whatever packages/classes you don’t normally want to see when debugging. I’ve added things like:

• org.apache.commons.logging.*
• org.springframework.aop.*
• org.springframework.jdbc.*

etc. I could have just added org.springframework.*, but wanted to be more specific.

Then, when debugging, ensure that Step Filtering is activated (available in the preferences, but also an icon in the Debug Perspective. Now when you do step into, step return etc, the items you’ve requested to be filtered out will be.

One thing I’ve noticed. On the preferences dialog, when you choose Add Packages…, be patient. It takes Eclipse awhile to build up the list of packages to select from, but I think it’s worth the wait…

Just had this problem. Run my server external to Eclipse, and use a debug connection.

Breakpoint set, but when stops, Eclipse complains can’t find source.

Clicking the ‘edit Source path’ button, I could see the source folders there. Eclipse would flash the source code, and then very quickly go to the ‘source not found…’.

Finally modified the paths. Rather than using explicit folders, I removed all the folders, and did add project… This appears to be what Eclipse requires.

Documenting for others that have run into it, and for myself the next time I experience it, and have forgotten what I did to fix it…