Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jdt-debug-dev] Re: [platform-debug-dev] Debug Work Items for 2.1 and Beyond

Hello,

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.

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

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.

4. We have no way of calling the shutdown method of JDIDebugTarget
because shutdown is not defined in IJavaDebugTarget, and the jdt
plugin class that is responsible for shutting down the debug target
expects a JDIDebugTarget to be registered, which it isn't (ours is).

5. The use 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.)


Regards,

David


Darin Wright wrote:
> 
> Not yet. We are still eagarly waiting for input from other developers
> to help prioritize the features we will work on. If there are any
> features/bugs/issues that are important to you, please let us know.
> 
> Darin
>


Back to the top