> 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
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]>:
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_______________________________________________
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
