search

mozilla / rhino

Rhino is an open-source implementation of JavaScript written entirely in Java
https://rhino.github.io
Other
4.15k stars 846 forks source link

Implement Debug Adapter Protocol #973

Open p-bakker opened 3 years ago

p-bakker commented 3 years ago

In order to be able to use Rhino in modern develoment setups, I propose to implement the Debug Adapter Protocol, which is how VS Code and Wild Web Developer (Eclipse) offer an extendible debug targets

I wonder if anyone uses the Swing-based debugger that in part of Rhino and I know there's a implementation based on the dbgp protocol in DTLK, which is used by some, but all platforms nowadays seem to move towards DAP

p-bakker commented 3 years ago

Within Java land, there's lsp4e, to aid easier implementation of both DAP and Language Servers

Example of DAP implementation for Kotlin: https://github.com/fwcd/kotlin-debug-adapter Useful link regarding LSP4E docs: https://github.com/eclipse/lsp4j/issues/258

p-bakker commented 3 years ago

Curious to know if anyone uses any form of a debugger for debugging just JavaScript running in Rhino

c3-mgruchacz commented 3 years ago

Hi @p-bakker, wondering if there's any update on implementing Debug Adapter Protocol for Rhino?

Thanks!

p-bakker commented 3 years ago

While I wish I had time to work on this, I haven't. I created this case as part of establishing idea's for the Rhino roadmap.

If you're interested in contributing, I'm happy to share my ideas

tonygermano commented 3 years ago

I wonder if anyone uses the Swing-based debugger that in part of Rhino

I do occasionally, but I wouldn't say I'm a heavy user. I have it configured as a build task in vscode so I can launch it from there.

c3-mgruchacz commented 3 years ago

Yes, I'm interested, I would like to hear your ideas. I think the lsp4j project that you reference in post 2 is a good starting point, essentially implement the IDebugProtocolServer interface, mapping each method to the corresponding action in the rhino debugger class Dim.

p-bakker commented 3 years ago

Great to hear!

Yeah, I think using lsp4j as a basis, so you can focus on just the wiring things up into Rhino would be the best approach.

As for the wiring up into Rhino, bottom-line, you'll need an implementation of org.mozilla.javascript.debug.Debugger that can be registered on a Context using .setDebugger(...)

You could start implementing org.mozilla.javascript.debug.Debugger from scratch or take an existing implementation that already has implemented a lot of features like breakpoints etc., as the Debugger interface is nothing more that a hook into the internal Rhino JavaScript callstack.

As for the existing implementations: the current Swing-based debugger in the tools section that comes with Rhino would be one starting point, but that debugger isn't that feature rich.

As mentioned above, I know of at least one other implementation, namely the one based on the DBGP protocol in the DTLK project.

Personally, I regularly use a (custom) version of the debugger in DLTK and its close to being as feature rich as the Java Debugger in Eclipse (imho the only notable omission being Drop to Frame). The source of this custom version is also available: https://github.com/Servoy/servoy-js-engine/tree/master/org.eclipse.dltk.javascript.rhino/src (the Rhino side) and https://github.com/Servoy/org.eclipse.dltk.javascript/tree/servoy/plugins/org.eclipse.dltk.javascript.debug (server/debugger side)

If I would attempt to implement DAP, I think I'd start looking to see if I could reuse large chunks of this DBGP-based implementation.

When doing so, I'd first look at whether it would be ok to copy & modify the DLTK code: I think its EPL based, but it's not clearly mentioned on the repo and even if it's EPL-based, I'm not sure what that implies with regards to copying that code and using it as a basis for something else under a different license

One more note: neither the DBGP debugger and Swing-based one support Symbols (both were implemented before symbols were added to JavaScript) and probably also aren't aware of async calls (using the just landed Promises implementation and async function (when those are implemented))

p-bakker commented 2 years ago

Just as reference:

p-bakker commented 11 months ago

And some more pointers: based on this discussion, at least 2 remote debugger implementations were being worked on at one point in time, one of them by @szegedi, which can still be found at https://sourceforge.net/p/dynalang/code/HEAD/tree/trunk/debug-rhino/ (Apache License) and one at https://eclipse.googlesource.com/e4/org.eclipse.e4.languages/+/refs/tags/I20140331-2200/bundles/org.eclipse.e4.languages.javascript.debug.jsdi/src/org/eclipse/e4/languages/javascript?autodive=0 (EPL licensed)

From my experience looking into this, you need a fair bit of code to manage state between the client and server and my previous idea was to use the DLTK implementation, but it being EPL licensed as well stopped me from continuing. With the dynalang implementation being Apache licensed, that might offer a more viable path for jumpstarting any DAP implementation

p-bakker commented 11 months ago

another Rhino Debug impl., Eclipse Ease this time: https://gitlab.eclipse.org/eclipse/ease/ease/-/tree/main/plugins/org.eclipse.ease.lang.javascript.rhino/src/org/eclipse/ease/lang/javascript/rhino/debugger?ref_type=heads

And seems to maybe already do some DAP-related stuff, as this commit introduces support for WildWebdeveloper breakpoints, which, from a quick glance at the changes, seem to be LSP4J breakpoints

tonygermano commented 11 months ago

Since my original comment two years ago, https://github.com/nextgenhealthcare/connect now integrates the swing debugger into their product (but it doesn't allow remote debugging, which limits its use as it typically runs on headless systems.)