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

Bug 346265

Summary:	Filter Java classes that users won't want to step into [basic]
Product:	z_Archived	Reporter:	Justin Spadea <jspadea>
Component:	EDT	Assignee:	Justin Spadea <jspadea>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Justin Spadea

2011-05-18 10:42:03 EDT

The following should be filtered during an EDT debug session: EDT Java runtime, any other contributed generator runtimes, JRE classes, etc.

JDT's step filters would work perfectly for this, however they intentionally disable step filters for non-Java stratums. I've opened an RFE for them to support this, however the earliest it could be added is 3.8. https://bugs.eclipse.org/bugs/show_bug.cgi?id=344165

The nice thing about step filters is it provides a good UI for letting users decide what is and isn't filtered, so they can have our runtimes filtered but not their own custom classes, allowing them to step into their Java external types. It also makes it easy for debugger developers to turn off step filters to see what's going on in the generated code.

Comment 1 Justin Spadea

2011-07-25 17:35:57 EDT

Modified EGLJavaThread.java to do some hard-coded filtering on JRE and runtime packages. To disable the filtering, you can launch eclipse with a vm arg:

-Dedt.debug.filter.runtimes=false

For JRE classes we force a stepReturn, while for runtime classes we force a stepIn. This will allow runtime code to step into generated code. We only do the stepIn/stepReturn if we're suspending in one of the filtered types due to the end of a step request.

If JDT ever lets us use their step filters, we can remove this filtering and switch to that, which would work a lot better.

Comment 2 Justin Spadea

2011-09-07 16:28:22 EDT

Verified