Yes, that's just the stuff I'd found out for so far (i.e. DebuggerSupport according to JDK-8044798), see my first message. I've also looked at NetBeans sources to get an understanding of how to gather of script source line info by tracking ClassPrepare events for jdk.nashorn.internal.scripts.Script* classes. That looks like the easier part of the story.
The harder part (at least for me) is how to fit this into the JDT and JSDT design. (I'm familiar with Eclipse plugin development in general, but not really with J(S)DT details.)
So far, I've created an alternative NashornLaunchDelegate for the standard Java debug launcher to create extra breakpoints for DebuggerSupport and Script* classes in the JDIDebugTarget. This should eventually let me step from Java into _javascript_ code invoked from a plain old Java application via ScriptEngine. (Directly launching a *.js source like jjs does would be a different story, which I'm not considering for now.)
There were two issues:
- JavaClassPrepareBreakpoint does not handle wildcards in class names. I had to extend this class.
- ReferenceType.allLineLocations() throws an AbsentInformationException when at least one of the methods of the type has no line info. The JDK implementation returns all line info that's available and only throws an exception when NONE of the methods have line locations. The JDI Javadoc is a bit vague about this, but I would consider this as a JDT bug. (The point is that the Script* classes generated by Nashorn do contain line locations only for those methods corresponding to _javascript_ functions or top-level scripts, and there are some other methods without line info.) As a workaround, I iterate over the methods myself.
Now my next idea is to create a new IJavaScriptDebugTarget implementation which delegates to the JDIDebugTarget, transforming _javascript_ debugger commands/events to JDI commands and events and vice versa. Does this make sense?