Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 44758

Summary: Runtime resolve of packages from other project is not possible in conditional breakpoints
Product: [Eclipse Project] JDT Reporter: Max Rydahl Andersen <max>
Component: DebugAssignee: Darin Wright <darin.eclipse>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: darin.eclipse
Version: 3.0   
Target Milestone: 3.0 RC2   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
patch for JavaSourceLookupParticipant none

Description Max Rydahl Andersen CLA 2003-10-13 10:36:47 EDT 
If you have project1 and project2 (where project2 uses project1),
it used to be you could create a conditonal breakpoint in project1 where you 
refferred to classes in project2.

This is still possible, but you get a "Cannot resolve <project2 classname>" 
error.

This is not very logical since the debugger has no problem inspect, evaluate or 
navigate the project2 class at a breakpoint inside project1.

So, it should be possible (it was before) to add conditional breakpoints with 
instanceof checks that uses classes from other projects - as long as the classes 
are available at runtime.
Comment 1 Luc Bourlier CLA 2003-10-13 16:19:56 EDT 
I'm not sure that was working before, but we should be able to improve the
evaluation in this case.
The specifique problem here, is that the compilation for the evaluation is done
in the project of the declaring type instead of the project of the recieving type.
Comment 2 Darin Wright CLA 2004-05-28 10:58:47 EDT 
deferred to RC2
Comment 3 Luc Bourlier CLA 2004-06-09 14:41:41 EDT 
Implemented.

The evaluation for the condition is now done in the context of the project of
the receiving type. The classes, static methods and static fields visible in the
project of the receiving type can be used in the evaluation.

Note that if the instance where the breakpoint is stopped is from project 1, the
same error will be displayed when trying to evaluate a condition referencing a
type in project 2.

JDIReferenceType - added method getSourcePath() to get the source path for the
default stratum.
JavaSourceLookupParticipant - modified to be able to do source lookup on
reference type.
JavaLineBreakpoint - modified getJavaProject() to return the project of the
recieving type if possible.
Comment 4 Luc Bourlier CLA 2004-06-09 14:46:02 EDT 
Created attachment 11819 [details]
patch for JavaSourceLookupParticipant

Looks like I don't have commit right on jdt.launching ... ?
Comment 5 Luc Bourlier CLA 2004-06-09 14:47:10 EDT 
Please verify, Darin W.
Comment 6 Darin Wright CLA 2004-06-09 15:07:25 EDT 
There's an NPE in JavaLineBreakpoint:

java.lang.NullPointerException
	at 
org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.getJavaProje
ct(JavaLineBreakpoint.java:482)
	at 
org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.handleCondit
ionalBreakpointEvent(JavaLineBreakpoint.java:443)
	at 
org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.handleBreakp
ointEvent(JavaLineBreakpoint.java:368)
	at 
org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent
(JavaBreakpoint.java:263)
	at org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch
(EventDispatcher.java:172)
	at org.eclipse.jdt.internal.debug.core.EventDispatcher.run
(EventDispatcher.java:221)
	at java.lang.Thread.run(Thread.java:534)
Comment 7 Darin Wright CLA 2004-06-09 15:15:23 EDT 
I think the NPE is in static methods? You should have update rights to 
launching. I fell back these changes since this breaks the test suite (NPEs).
Comment 8 Darin Wright CLA 2004-06-09 15:16:25 EDT 
(as well, the API reference from launching to JDIReferenceType is illegal - 
i.e. plug-in acccessing internal type from another plug-in. Is there anyway we 
can make it work without adding API?)
Comment 9 Darin Wright CLA 2004-06-09 15:24:49 EDT 
Luc, we can like get an API addition to IJavaReferenceType if we need it (i.e. 
getSourceName/getSourcePath for a specified stratum). Would that be helpful?
Comment 10 Luc Bourlier CLA 2004-06-09 16:30:08 EDT 
If we add a String[] getSourcePath(String stratum) to IJavaReferenceType, we
don't need to reference an internal class. I thought that the API were frozen
(it's not a breaking change, but ...).
Comment 11 Darin Wright CLA 2004-06-09 16:41:48 EDT 
We'd still need PMC approval to add the method.

This is a better idea - just pass in the string to the source locator - it 
handles them as file names. You're already in the java debug model, so you can 
add the "private API" method and access it from JavaLineBreakpoint, where you 
need it. Then we don't need the API method.
Comment 12 Luc Bourlier CLA 2004-06-09 17:20:21 EDT 
That works too.
The NPE was in the context of static methods, getThis() return nulls. Added a
test to check for the receiving type only in non-static context. I reworked
getSourcePath() to something that looks more like what we need in the API.

JavaLineBreakpoint - modified getJavaProject() to return the project of the
recieving type if possible.
JDIReferenceType - added method getSourcePaths(String stratum) to get the source
paths for the given stratum.
Comment 13 Luc Bourlier CLA 2004-06-09 17:20:44 EDT 
Please verify, Darin W.
Comment 14 Darin Wright CLA 2004-06-10 11:03:18 EDT 
Verified: We can only reference types the receiving type's build path 
includes. We base visibility on the receiving type, and if the receiving type 
cannot see the upstream type, we cannot compile the expression.