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

["Darin Wright" <Darin_Wright@xxxxxxx>]

I think that problem #1 and #3 are related...(just expanding on some issues here - no solutions yet).

The JDT debug model interfaces (IJavaStackFrame, etc), were not intended to be implemented by clients. In fact, the java doc for each interface explicitly states "Clients are not intended to implement this interface". Thus, the implementation freely casts to internal implementation classes, as it was to be the only implementation.

Some of our action contributions are constributed/enabled based on the instance of elements in the UI. Thus, we may test that the selected stack frame, is an IJavaStackFrame in order to enable "open on <x>". Again, since there was only to be one implementor of IJavaStackFrame, the action contribution problem in problem #1 was not forseen.

With that said, this is (at least) the second instance of clients implementing the Java debug model interfaces in order to create a debug model for a launguage which is compiled to Java (which breaks the API contract specified). There could be many issues here, as the implementation of more complex actions/operations may rely on an internal implementation (for example, _expression_ evaluation). As well, problem #1 may be more complex. That is, should all the "JDT debug model" actions not be present for wrappering debug models, or are some of the actions still valid? In the case where some actions are still valid, then neither "instanceof" or debug model identifier will work as a selection criteria.

It appears that the JDT debug model is being used in a way that we had not intended - with some success :-) Perhaps we can come up with some ways to make things play a little better in the future.

Darin

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

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