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

Bug 344165

Summary: Add option to allow step filters on non-Java stratums
Product: [Eclipse Project] JDT Reporter: Justin Spadea <jspadea>
Component: DebugAssignee: JDT-Debug-Inbox <jdt-debug-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: loskutov, Michael_Rennie, ndsilva, sven.efftinge, swanj, thatnitind
Version: 3.7   
Target Milestone: ---   
Hardware: All   
OS: All   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=89643
https://bugs.eclipse.org/bugs/show_bug.cgi?id=519926
Whiteboard:

Description Justin Spadea CLA 2011-04-28 13:27:06 EDT
Build Identifier: 3.6.2

I'm working on a debugger for the EDT project, making use of JSR 045 (SourceDebugExtension). With EDT one of your options is to generated Java code from your EGL code. The default stratum for our generated Java classes is "egl". The source mapping and stratum breakpoints are working, however the step into action will step into any Java runtime code. EGL programmers don't care about the Java code, they want to "debug EGL". I was looking at how we could filter out classes like our runtime, and step filters seemed a perfect match - but then I noticed it's intentionally disabled for non-Java stratums (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=89643).

A single step into can lead to many Java invocations (StringBuilder, Classloaders, etc) that is going to confuse EGL developers (many of whom do not know Java). A single line of EGL code, e.g. "doSomething( someVariable );" can require several stepInto/stepReturn statements on the Java runtime classes until it finally goes into the "doSomething" function, due to all of what's happening in the underlying Java code (creating temp objects, assigning values, etc).

As for the suggestion in the above-mentioned bugzilla "Filter non-Java resources", this wouldn't fully meet our needs. There are some Java types that users will want to step into (e.g. they can invoke their own custom Java code from EGL, so they'd want to be able to step into their own classes). If the option was "Allow step filters on non-Java stratums" then it would meet our needs. We could provide a set of default filters for our runtime classes, and users could add any others if they want. Or if you don't want it a user configuration option, an extension point where we could say "egl stratum wants step filters enabled" would suffice.

Reproducible: Always

Steps to Reproduce:
I can't provide a test case until the EDT debug code is added to Eclipse CVS sometime next week. But the code in JDT is JDIThread.StepHandler.attachFiltersToStepRequest().
Comment 1 Sven Efftinge CLA 2012-03-01 05:28:03 EST
+1 for an option "Allow step filters on non-Java stratums"