How would you deal with re-entrancy though, e.g. Java -> JS -> Java -> JS
If you simulate a synchronous call from JS to Java by breaking, what happens when Java calls back into JS? Everytime I thought about doing this, it basically boils down to emulating continuations with CPS transform, and that is quite onerous. It seems much simpler to get the IDEs to support SourceMaps. For example, IntelliJ already supports attaching to Firefox and Chrome JS debuggers, once it supports SourceMaps, you should be able to have a Java-debugger like experience with SDM. On Wed, Dec 12, 2012 at 9:42 AM, Thomas Broyer <t.bro...@gmail.com> wrote: > Hi, > > A few years ago I started working on DevMode support for Adobe AIR > applications. The idea was to implement a ClientBrowserChannel that > connected to the DevMode, launched the app in debug mode (through the ADL > tool of the Air SDK) and plugged into the debugger, replacing the DevMode > plugin with breakpoints and variable manipulation (when the breakpoint is > reached, read a couple variables using the debugger API and send them to > DevMode, when a message comes back from DevMode, update those variables and > resume execution until the breakpoint is reached again; rinse and repeat). > At that time, I made a few changes to BrowserChannel to make it possible, > and the changes were merged upstream. I never finished it as I never managed > to set the breakpoint in the AIR environment. > > Given that it's becoming increasingly hard to support the DevMode plugin for > Firefox and Chrome, that those two browsers now have a remote debugging > protocol (each one their own unfortunately), and that SuperDevMode is a > different "experience" that some people don't like; I wondered if you ever > thought about such an approach as a replace for the DevMode plugin? The > downside would be that you'd have to launch the DevMode, then launch > "browser launchers" for each browser you want to debug (that acts as a > bridge between the DevMode protocol and the browser's own protocol). > I suppose that it would be rather easy (though a matter of days, not hours) > to build a prototype using the ChromeDevTools SDK (reading the docs, setting > the breakpoint should be easier than with the AIR SDK). > > An alternative could be using the browsers' debugger APIs in a browser > extension (the extension detects the ?gwt.codesvr= and sets a breakpoint in > the devmode.js, it can then talk to the DevMode using asynchronous network > APIs –e.g. WebSocket–, the breakpoint in the page guarantees that the > "application code" runs "synchronously", just like with the plugin nowadays; > there could be a global var in devmode.js that would be modified by the > "debugger" to disable loading the plugins, so the devmode.js is backwards > compatible). The downside is that the debugger API in Chrome cannot be used > at the same time as the developer tools. > > I'm just throwing the idea here, in case anyone's interested in pursuing it, > as an alternative to SuperDevMode, to continue running the code "in Java", > debugged using your preferred Java debugger. > > Note that Opera also has its own remote debugging protocol (for much longer > than the others) and could thus gain plugin-free DevMode support. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
