| Author |
Eclipse JDI-like support for plugin
|
Brian Colan
Greenhorn
Joined: Jul 03, 2003
Posts: 5
|
|
Hello, I am trying to build a graphical representation of a program in execution. I have this working as a standalone project and now I need to integrate it into Eclipse for it to be useful to other developers. However, I am having trouble because unlike Sun's JDI (which I cannot use with Eclipse compiler) your debug.core API does not expose the events in its API e.g. method entries/exits, object creation, etc.. I also need to allow the user to be able to set and unset breakpoints from the plugin (you can think of it as a graphical front-end to the debugger since it needs much of the same functionality and needs to be in sync/control the Eclipse debugger) I am interested to hear your suggestions on how I should work around this, I have been looking at some profilers for Eclipse (since I am interested in getting much of the same information as a profiler) and one of them (Eclipse Colorer) uses a JVMPI dll but I am unsure how to go about this ? I have been working with aspecjt (ajdt plugin) to get tracing information and this is excellent but how can I coordinate this with the Eclipse debugger and let the user set breakpoints etc ? Thank you for your time and I look forward to your suggestions Best Regards, Brian C.
|
 |
Ed Burnette
Author
Ranch Hand
Joined: Jun 10, 2003
Posts: 142
|
|
Originally posted by Brian: Hello, I am trying to build a graphical representation of a program in execution. I have this working as a standalone project and now I need to integrate it into Eclipse for it to be useful to other developers. However, I am having trouble because unlike Sun's JDI (which I cannot use with Eclipse compiler) your debug.core API does not expose the events in its API
Sounds like a neat project. The Eclipse debugger *does* use the standard JDI interface to talk to the target JVM under the covers. As you've found though it's not especially extensible itself. Luckly all the source is there so you can modify it to add whatever hooks you like, and contribute the extension points back to the community. So I'd start by looking at the internal implementation of the debugger, how it interfaces with the target JVM. Then try to call internal functions where public ones aren't available, modifying the code if there's no internal function. After you get everything working then fill out bugzilla reports to make the internal api you used public or add the new api/extensions you had to create. HTH.
|
Ed Burnette, Author of Hello Android
Blog: ZDNet's Dev Connection - Twitter: @eburnette
|
 |
 |
|
|
subject: Eclipse JDI-like support for plugin
|
|
|