Implement Debug Adapter Protocol

[p-bakker]

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]

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: eclipse-lsp4j/lsp4j#258

[p-bakker]

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

[c3-mgruchacz]

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

Thanks!

[p-bakker]

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]

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]

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]

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]

Just as reference:

• Another Rhino Debugger implementation: https://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.debug.rhino.debugger/src/org/eclipse/wst/jsdt/debug, https://wiki.eclipse.org/JSDT/Debug/Rhino/Embedding_Rhino_Debugger#Testing_Remote_Rhino_Locally
• And an extension of the Swing-base Debugger: https://github.com/nextgenhealthcare/connect/tree/development/server/src/org/mozilla/javascript

[p-bakker]

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]

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]

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.)