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

[David Sanders <dsanders@xxxxxxxxxxx>]

This function is mainly for us dummies and/or beginners that forget or 
don't know to set a breakpoint prior to debugging.  (If a person is 
doing remote debugging then they are taking extra steps anyway.)  The
one problem that I see with doing this for one but not the other is 
inconsistency, resulting in a less intuitive interface.

How do other java debuggers out there handle this, or do they?

Regards, 

David


Darin Wright wrote:
> 
> 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:                                      To:
>  platform-debug-dev-admin@xxxxxxxxxxx   platform-debug-dev@xxxxxxxxxxx
>                                                cc:
>  08/12/2002 04:32 PM                    jdt-debug-dev@xxxxxxxxxxx
>  Please respond to platform-debug-dev          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