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

["Darin Wright" <Darin_Wright@xxxxxxx>]

For #5 below (stop in main) - do you expect this to work for "local java apps" only, or also "remote java apps"?

There is a technical issue: Setting a method entry breakpoint for a fully qualified method (i.e. type name, method name & signature) exhibits good performance (the same overhead as a line breakpoint). Setting a method entry breakpoint for a method name (i.e. any method named "main"), exhibits poor performance. I assume that stepping into main is only useful in the "local" case where you actually launch main (and we know the fully qualfied method name/signature). In the remote case, chances are that the "main" method is already long gone (and we do not know the name of the main class).

(See bug 20869 for an explanation of method entry/exit breakpoints and related performance issues).

Thus, I propse to add support for "stop in main" to local Java apps only. Do we agree?

Darin

David Sanders <dsanders@xxxxxxxxxxx> Sent by: platform-debug-dev-admin@xxxxxxxxxxx 08/12/2002 04:32 PM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:        jdt-debug-dev@xxxxxxxxxxx         Subject:        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
>
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev