yoannbuch / jive Goto Github PK

Purpose of code changes on this branch:

See issue 4.

After the review, I'll merge this branch into:
/trunk

A StepRequest is created once for each thread using StepRequest.STEP_INTO.  
Previously, a request was created using StepRequest.STEP_OVER each time a 
MethodEntryEvent was received.  Since changing to StepRequest.STEP_INTO, it 
is no longer necessary to create StepRequests in this manner.  While 
JiveThread only creates a single StepRequest, JiveDebugTarget is still asking 
it to create a request at each method entry.  This results in a small 
inefficiency but no observable differences in event traces.

Purpose of code changes on this branch:

See issue 2.

After the review, I'll merge this branch into:
/trunk

JiveThread inherits from JDT Debug's JDIThread class.  The stepping methods 
in this class were changed in revisions 1.182 and 1.192 but were not 
updated accordingly in JiveThread:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.debug/model/org/ec
lipse/jdt/internal/debug/core/model/JDIThread.java?
r1=1.181&r2=1.182&diff_format=l
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.debug/model/org/ec
lipse/jdt/internal/debug/core/model/JDIThread.java?
r1=1.191&r2=1.192&diff_format=l

This results in inaccurate stack frame UI elements and potential deadlocks.  
See the related Eclipse bugs for details:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=215489
https://bugs.eclipse.org/bugs/show_bug.cgi?id=265037

When running multi-threaded programs, some threads are shown as suspended in 
the Debug view when they are actually running.  This does not occur in 
Eclipse 3.3 but does occur in Eclipse 3.4 and later.  It is likely a result 
of a change made to JDT Debug's JDIThread class (revision 1.183):

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.debug/model/org/ecli
pse/jdt/internal/debug/core/model/JDIThread.java?
r1=1.182&r2=1.183&diff_format=l

Purpose of code changes on this branch:

See issue 5.

After the review, I'll merge this branch into:
/trunk

The JDIToJiveEventAdapter re-write did not implement generation of 
AssignEvents for local variable changes.  This needs to be completed for 
the next release.  The following should be kept in mind when implementing 
this:

(1) Local variables in disjoint scopes can have the same name.

(2) The return value of java.lang.Object.clone() will not have an 
associated NewEvent for unfiltered classes.  It should be generated first 
if possible.

(3) The CatchEvent variable can possibly be inferred here.  It does not 
come into scope (if at all) until after one step, so we are always missing 
it right now.