Harald, it is good to now we are not alone who is interested in JSDT being alive and usable. Victor (JSDT project lead) and I can assist you if you need any help to push your contribution to JSDT repository. There is no github.com mirror right now for webtools.jsdt repository see https://bugs.eclipse.org/bugs/show_bug.cgi?id=459814 for details, feel free to share your changes in any form and we will glad to help to push it through contribution process.
Thanks Denis On Wed, Mar 18, 2015 at 12:18 PM, Harald Wellmann <[email protected]> wrote: > Max and Michael, > > thanks for your feedback and advice so far. I'll be happy to submit > Bugzilla issues and share my code, though not before next Tuesday, as I'll > be away for a while. Sharing the code might take a bit longer, I'm mainly > kicking tyres at the moment, so I'd like to clean things up first. > > I'm working with Luna SR1 at the moment, using the latest JSDT sources > from Git in my workspace. (I.e. JDT is from Luna SR1.) > > I have some standalone tests (i.e. not using Eclipse) launching a Java VM > with a simple Java/Nashorn/Javascript class via JDI and settings > breakpoints and inspecting Nashorn classes directly via the JDI API. The > script classes only have the default Java stratum - it would be interesting > to know why Nashorn developers did not add a JS stratum, they probably had > a reason for that. So I don't think upgrading to a Mars snapshot would make > a big difference in this respect. > > Anyway, via DebuggerSupport, you can obtain SourceInfo for each script > class, and this is enough to map the line numbers from the Java stratum to > the JavaScript source files. > > The point with the wildcard ClassPrepareBreakpoint is: Nashorn generates > one or more Java classes from each JS source file, it seems there is at > least one additional class per JS function. The class names satisfy the > naming pattern jdk.nashorn.internal.scripts.Script$*, but there is no way > to determine the suffixes beforehand, so the easiest way of implementing > something like a ScriptLoad breakpoint is to use a ClassPrepareBreakpoint > for this pattern and to expect this to be triggered multiple times per > script file, each class contributing a couple of Locations from the given > file. > > This works fine in my stand-alone test. With JDT, I can set the > breakpoint, but my breakpoint listener does not get called, since the JDI > event handler compares class names by equals() and does not fire a > breakpoint event for the pattern match. > > Regards, > Harald > > > 2015-03-18 16:17 GMT+01:00 Michael Rennie <[email protected]>: > >> > 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. >> >> This is pretty much the same way the JSDT works (for Rhino anyways). We >> listen for script compilation events and build up a model / line infos / >> etc. on the fly. >> >> For specific examples have a look at the following bundle: >> >> >> http://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.debug.rhino.debugger >> >> > 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.) >> >> In JSDT the design basically has you provide a way to launch the backend, >> the connector to talk to it, and you get the UI for *free*. See the *.rhino >> or *.crossfire bundles in JSDT for examples. >> >> In JDT we support Java and debugging in the VM via JDI and alternate >> stratums - we do not have any code in the Java debugger for specific >> languages other than Java. >> >> > 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. >> >> Your idea sounds like a really good place to start, but I am surprised >> this doesn't "just work" with JDI and alternate strata. Perhaps the >> classfiles created do not properly create an alternate strata that JDI can >> use, or JDT debug has more bugs in it? >> >> Which version of Eclipse are you developing / testing this against? The >> Xtext/Xtend folks provided a lot of fixes around alternate >> strata in the Java debugger in Mars, which might help here. >> >> > (Directly launching a *.js source like jjs does would be a different >> story, which I'm not considering for now.) >> >> This would probably be very similar to: >> http://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.debug.rhino.debugger/src/org/eclipse/wst/jsdt/debug/rhino/debugger/shell/DebugMain.java >> >> Can you open a bug in JSDT debug about direct Nashorn debugging? It would >> be good to have support for this built right in. >> >> >> > There were two issues: >> > - JavaClassPrepareBreakpoint does not handle wildcards in class names. >> I had to extend this class. >> >> This should be simple enough to fix. Can you open a bug in JDT debug for >> this? >> >> > - 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. >> >> This also sounds wrong. Can you open another bug (in JDT debug) for this >> as well? >> >> >> > 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? >> >> That sounds like a cool idea. >> >> I have not tried debugging in Nashorn yet (with JDI or otherwise), so I >> can't say for sure why it doesn't work as-is (with JDI and the standard >> Java debug target), but it really feels to me like it should. >> >> Have you tried debugging through the JDI code to confirm your suspicion >> about there only being a Java strata? >> >> Perhaps throw a breakpoint in ReferenceTypeImpl#allLineLocations around >> line 1991 to see what stratum ID it asks for / thinks it has (using a >> normal JDI connection)? >> >> Michael Rennie >> >> [image: Inactive hide details for Harald Wellmann ---17/03/2015 06:17:58 >> AM---Yes, that's just the stuff I'd found out for so far (i.e.]Harald >> Wellmann ---17/03/2015 06:17:58 AM---Yes, that's just the stuff I'd found >> out for so far (i.e. DebuggerSupport according to JDK-8044798), >> >> From: Harald Wellmann <[email protected]> >> To: "General discussion of project-wide or architectural issues." < >> [email protected]> >> Date: 17/03/2015 06:17 AM >> Subject: Re: [wtp-dev] Nashorn Debugging >> Sent by: [email protected] >> ------------------------------ >> >> >> >> 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]* >> <[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* >> <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* >> <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]* <[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* <http://about.me/maxandersen> >> >> On 14 Mar 2015, at 19:24, Harald Wellmann < >> *[email protected]* <[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* >> <https://developer.jboss.org/message/920239> >> >> Best regards, >> Harald >> _______________________________________________ >> wtp-dev mailing list >> *[email protected]* <[email protected]> >> To change your delivery options, retrieve your password, >> or unsubscribe >> from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/wtp-dev* >> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> >> _______________________________________________ >> wtp-dev mailing list >> *[email protected]* <[email protected]> >> To change your delivery options, retrieve your password, or >> unsubscribe >> from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/wtp-dev* >> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> >> _______________________________________________ >> wtp-dev mailing list >> *[email protected]* <[email protected]> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/wtp-dev* >> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> >> >> >> /max >> *http://about.me/maxandersen* <http://about.me/maxandersen> >> >> >> /max >> *http://about.me/maxandersen* <http://about.me/maxandersen> >> _______________________________________________ >> wtp-dev mailing list >> *[email protected]* <[email protected]> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> *https://dev.eclipse.org/mailman/listinfo/wtp-dev* >> <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 >> > > > _______________________________________________ > 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
