Re: [jdt-debug-dev] Debug Work Items for 2.1 and Beyond

["Darin Swanson" <darins@xxxxxxxxx>]

> Here are some of the issues we've come across when wrapping the
> jdt debug model:
>
> 1. One issue that we have when wrappering the jdt debug model is
> that we have no way to override the jdt menu contributions to the
> launch and variable views (that we know of).  Specifically the
> 'open on <x> type' menu items.  These show the underlying java source
> code, which is not the language that the user is debugging.  I would
> say that the solution would be to base the menu items on the current
> debug target id, but I'm not sure if this is the solution.
>

This is great as it might validate my work for today ;-).
I reworked the "Open on" menu items to request the source element from the
source locator for the launch.  So your source locator can be reused to just
do the right thing?
We only resort to searching the workspace if this fails.  See bugs:
http://dev.eclipse.org/bugs/show_bug.cgi?id=5516
http://dev.eclipse.org/bugs/show_bug.cgi?id=4084

Of course with actions that simply do not make sense in your context, you
can remove the contribution from the XML.

> 2. Another issue that we have is that our program programmatically
> sets underlying java breakpoints whenever the user sets a breakpoint
> in their source code (which is in another language).  It would be
> nice if these java breakpoints could be 'invisible' in the breakpoint
> view by default.  Currently, the user has to set the 'show only
> supported breakpoints' option.  It would be nice if there was a
> visibility option and the breakpoint view would not show invisible
> breakpoints by default (the user could override this, of course).

I believe this is covered in our concept of registering/not registering the
breakpoint with the breakpoint manager?
For example, we programmatically set breakpoints for the "Run to Line"
functionality.  These are not registered (part of the api on the call to the
debug model to create a line breakpoint) and therefore do
not show up in the breakpoints view.

>
> 3. Some JDIDebugElement methods cast IJava<xx> elements to JDI<xxx>
> unnecessarily, even when the method needed to be called is defined by
> the IJava<xx> element.  This limits some of the ability for plugins
> to wrap/mimic these elements.

See bug http://dev.eclipse.org/bugs/show_bug.cgi?id=21823

>4.
Could you please log a bug report for this issue?

> 5. The user should have the ability to debug without setting a
> breakpoint.  (The debugger should be able to 'step into main'.  This
> is already on the list, I believe.)

see bug http://dev.eclipse.org/bugs/show_bug.cgi?id=5500

Thank you for the feedback

Darins