Question

Every once in a while I’m in the Eclipse Debug mode, and wish I could simply pick the Object that I am currently inspecting/watching, put some kind of “Object Breakpoint” on it, and step to the next line of code that accesses it.

Now, I know that I can put breakpoints on Classes, but I usually have hundreds or even thousands of instances in memory, most of which have a long life time. They often go in and out of frameworks. They are wrapped into Collections, filtered and unwrapped again. In short: a regular, large application.

Usually I still find the problem by looking for rare features of that Object, using conditional method breakpoints and a lot of informed guessing. However, I think I sometimes could be much faster if I had something like the described feature.

What I found after some searching is the Debug Proxy (scroll down to examples). It is a container class that will use Javas reflection API to make itself look like the contained Object, thus you can use it instead of the contained Object in your application. Being an InvocationHandler, the DebugProxy can now “intercept” invocations of methods in the contained Object.

Using the proxy for actual debugging is as easy as adding this line to your application.

IMyObject = (IMyObject) DebugProxy.newInstance(new MyObject());

I can then set breakpoints inside the DebugProxies source code.

However, there are at least two problems with this approach.

1. It works but it is still a hack, and there are a lot of features missing, such as filtering options.
2. The Proxy-Object cannot be down-cast to the implementing class.

The 2. problem is the more serious one. I was able to use the DebugProxy with Classes generated by EMF, and there is no problem to follow the Object throughout the Framework. However, when I am trying to debug code that doesn’t use interfaces for all interesting Classes, the DebugProxy will quickly fail.

Does anybody know about alternatives?
Maybe the Eclipse JDT Debugger already has such a feature and I simply don’t see it!?

I know there is the Java instrumentation API, and frameworks such as AspectJ. Could these be used to get a practical solution?

Answer 1

I added basic filtering to the DebugProxy and modified the output so Eclipse Console View shows a link to the calling line of code:

Problem number two remains unsolved, though. I put up the source code on GitHub. Maybe somebody will come up with something.

A completely different way to approach this would be to automatically add breakpoints with conditions comparing the current hashCode() with the HashCode of the Object in question. This may not be too difficult for someone who knows more about the JDT internals.