On Thursday, December 13, 2012 5:31:28 AM UTC+1, Ray Cromwell wrote:
>
> 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.
>
IIRC, ('cause I haven't looked at the code recently), it'd work the same as
today.
The idea is:
- implement a DevMode client in Java, equivalent to the C++ browser
plugins; this is easy, you just have to implement ClientBrowserChannel et
al.
- sending messages from the browser is done by setting a couple
variables and reaching a breakpoint, where the Java code then reads the
variables and sends the corresponding message to the DevMode server.
- sending a message to the browser is always done as a response, so
we're already stopped at the breakpoint, we can then set the variables and
resume execution, and the JS code will read the variables and do what's
appropriate (eval() code to load jsni methods, call a named function on an
identified object, etc.) Unless the message is a "return", the JS code
loops over and reaches back to the breakpoint. See
https://code.google.com/p/gwt-in-the-air/source/browse/branches/oophm/src/net/ltgt/gwt/air/tools/shell/Oophm.as
That was almost 3 years ago though, so I might have missed something
obvious at that time, and I must say I haven't wrapped my head back around
it nowadays. The "Chrome on Windows 8 doesn't support NPAPI" issue reminded
me about it recently.
> 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.
>
Some things don't behave the same though (inspecting variables to begin
with, IIRC). SuperDevMode is great when you have a lot of JSNI because you
can step into JSNI methods, but it won't ever give you the same experience
as debugging Java code running in a JVM. One big advantage of SuperDevMode
is that you run the code in JS so you're sure that's how it'll behave in
production and nothing will be "lost in translation" (as it's *already*
translated),
but sometimes you might prefer to trade this off for a "more integrated"
debugging (at least that's what the initial reactions to SuperDevMode
implied); and there's also the issue with GWT-RPC serialization policies
that make using SuperDevMode tricky (apparently, I don't use RPC).
I'm all for continuing investing in SuperDevMode *as a priority*. I just
wanted to know a) if you thought about that alternative and b) suggest it
as an alternative that someone could volunteer to pursue (as a side
project).
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
