[jdt-debug-dev] Release notification: Out of synch code.

[jared_burns@xxxxxxx]

StackFrame/Thread/Target synch notification released to HEAD.

These three debug elements will now display whether they are either known to be running code that is out of synch with the code in the workspace or may be running such code.

- Jared

"Darin Wright/WPG/OTI" <Darin_Wright@xxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 11/18/2001 11:27 AM Please respond to jdt-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [jdt-debug-dev] Out of synch code.

I like the suggestions below. 

I think there is a third case that we should also cover for failed HCR - i.e. when a target does not support HCR. We still need to show that the target is out of synch with the workspace in this case. Thus, I propose that in addition to what has been proposed, that when hot swap fails, a dialog could pop up with an error message explaiing hot swap failed in one or more targets. The dialog could have a "don't show this dialog again" check box so that the user can avoid having the "dialog in the face." This way, the user will get a quick lesson on what the red X's and yellow exclamation marks mean in the debug view, the first time a hot swap fails. The dialog could also be controlled with a user preference (i.e. warn when hot swap fails). (As an implementation detail, the new "java debug ui" plug-in could be the hot swap listener that reports the hot swap failure with a dialog). 

I am not sure how we control the "hover help" for items in a tree viewer. I do not recall seeing API in label providers to control the hover text. We may have to render the "is/may be out of synch" info in element labels. 

Darin

Jared_Burns@xxxxxxx Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 11/16/2001 04:51 PM Please respond to jdt-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx        cc:                Subject:        [jdt-debug-dev] Out of synch code.

Issue: 
- We want to show the user if the code running on the VM is the same as 
the code in the editor

Scenarios where this is necessary:
- Failed HCR. The code on the VM is the old code for the duration of the 
run.
- Successful HCR, failed drop to frame. The code on the VM is the old code 
until the next time the changed code is called.

UI recommendation:
After either of the above scenarios occurs:
- When suspended, out of synch stack frames (and parent thread, target) 
should render with a small red X in a circle (shrunken marker from the 
editors) appearing in the top left corner of the icon. Mousing over or 
clicking on the icon, will yield pop-up help informing the user that the 
code running in the VM is not the same as the code in the workspace.
- When running, threads (and parent target) will render with a small 
yellow exclamation point in a triangle (again, shrunken marker from the 
editors) appearing in the top left corner of the icon. Mousing over of 
clicking on the icon will yield pop-up help informing the user that the 
code running in the VM may not be the same as the code in the workspace. 
Red X's will take precedence over yellow !'s.

Implementation:
- Add API to JDIDebugElement: 
       #isOutOfSynch
       #mayBeOutOfSynch
       JDIModelPresentation uses this API to determine rendering
- Add API to JDIDebugTarget:
       #hasHCRFailed
JDIDebugTarget records which types have failed an HCR.
       JDIStackFrame answers #is/mayBe OutOfSynch by asking the
               debug target if hasHCRFailed and if the type it is in has failed an HCR.
               Stack frames will also be responsible for remembering when 
a drop to
               frame failed for their type after an HCR. If this is true, 
it will answer yes to
               isOutOfSynch.
       When suspended, JDIThread answers #is/mayBe OutOfSynch 
               by asking its stack frames if they are/may be out of synch
       When running, JDIThread answers #is/mayBe OutOfSynch by asking
               its debug target if hasHCRFailed.
       JDIDebugTarget answers #is/mayBe OutOfSynch by asking its threads
               if they are/may be out of synch

_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev