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? Regards, Harald 2015-03-17 11:37 GMT+01:00 Max Rydahl Andersen <[email protected]>: > Okey, so I reached out to netbeans guys and he confirmed to me it is > really underdocumented, but > apparently the DebuggerSupport class is part of the key and the only known > public documentation for it > is in this example: https://github.com/wickund/nashornexamples > > this is showing how a debugger can connect to nashorn over the debug > protocol. > > Interested in picking up that challenge ? > > /max > > > On 15 Mar 2015, at 9:27, Harald Wellmann wrote: >> >> Yes, it's a normal JDI connection. And it doesn't "just work", I'm >>> afraid, >>> nor do I see why it might. I don't know how it works with JSPs. Do >>> compiled >>> JSP classes contain a stratum with JSP line info? >>> >> >> Yes, the sourcelocation info on class'es would have a filename:linenumber >> piece of info. >> >> Nashorn script classes >>> only contain a Java stratum, as far as I can tell. >>> >> >> Yeah, I tried googling and apparently nashorn doesn't fit as smooth as >> rhino did. >> >> I'm still looking and will ask around but I did find this jira: >> https://bugs.openjdk.java.net/browse/JDK-8044798 >> which talks about jdk.nashorn.internal.runtime.DebuggerSupport being >> what is supposed to be used >> for external debuggers. >> >> I think thats what netbeans/intellij uses - but i'm not sure. >> >> /max >> >> >> Regards, >>> Harald >>> >>> >>> 2015-03-15 0:12 GMT+01:00 Max Rydahl Andersen <[email protected]>: >>> >>> Is the connection made over normal jVm debugging ? Then my guess is that >>>> it should "just work". Like with when debugging java with jsps. >>>> >>>> But otherwise it might be necessary to have both debuggers connected ? >>>> >>>> /max >>>> http://about.me/maxandersen >>>> >>>> >>>> On 14 Mar 2015, at 19:24, Harald Wellmann <[email protected]> >>>>> >>>> wrote: >>>> >>>>> >>>>> Continuing a conversation [1] started in the JBoss Tools Forum, I would >>>>> >>>> like to discuss what it would take to support mixed JavaScript/Java >>>> debugging on Nashorn with JSDT. >>>> >>>>> >>>>> This is a feature that works very smoothly in NetBeans, but is not >>>>> >>>> currently supported by official Eclipse projects or any third-party >>>> plugins, as it seems. >>>> >>>>> >>>>> Scenario: >>>>> >>>>> We are debugging a plain old Java application which embeds Nashorn via >>>>> >>>> javax.script.ScriptEngine and loads some JavaScript files. Some of the >>>> JavaScript functions call Java methods via Nashorn extensions. >>>> >>>>> >>>>> Using the Eclipse debugger, we can set breakpoints both in JavaScript >>>>> >>>> and Java sources and step through our application, from Java into >>>> JavaScript and back into Java, with the appropriate source lines being >>>> highlighted in the editor. >>>> >>>>> >>>>> In the call stack, we can see Java and JavaScript stack frames embodied >>>>> >>>> by method calls of generated Java classes. When selecting a stack frame >>>> corresponding to a JavaScript call, the variable inspector automatically >>>> switches from Java to JavaScript mode, so we can inspect JavaScript >>>> objects. >>>> >>>>> >>>>> >>>>> >>>>> So far, I've experimented with JDI and >>>>> >>>> jdk.nashorn.internal.runtime.DebuggerSupport and I sort of understand >>>> how >>>> to track scripts being loaded and how to map breakpoints to JavaScript >>>> source lines and vice versa. >>>> >>>>> >>>>> I've taken a look at JSDT and JDT sources, and I'm not quite sure how >>>>> >>>> this mixed source scenario would fit into the existing approaches. >>>> >>>>> >>>>> Implementing a new JSDI adapter for Nashorn along the lines of the >>>>> Rhino >>>>> >>>> debugger would only cover the JavaScript part. >>>> >>>>> >>>>> Would it be possible to start with a JDT debug launcher and extend it >>>>> or >>>>> >>>> create some kind of mixin to switch between the Nashorn/Java and >>>> JavaScript >>>> aspects of the same application? >>>> >>>>> >>>>> Are there any solutions for other JVM languages supporting >>>>> >>>> mixed-language applications that might serve as an example? >>>> >>>>> >>>>> [1] https://developer.jboss.org/message/920239 >>>>> >>>>> Best regards, >>>>> Harald >>>>> _______________________________________________ >>>>> wtp-dev mailing list >>>>> [email protected] >>>>> To change your delivery options, retrieve your password, or unsubscribe >>>>> >>>> from this list, visit >>>> >>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>>>> >>>> _______________________________________________ >>>> wtp-dev mailing list >>>> [email protected] >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>>> >>>> _______________________________________________ >>> wtp-dev mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>> >> >> >> /max >> http://about.me/maxandersen >> > > > /max > http://about.me/maxandersen > _______________________________________________ > wtp-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/wtp-dev >
_______________________________________________ wtp-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/wtp-dev
