Javascript debuggers can do most of the things you are asking for. The Chrome debugger can do conditional breakpoints, restart a frame (drop-in-frame), and I think it can also override JS values just fine. It can break on any exception (caught and uncaught) and inside the browser dev tools you can hover certain expressions and see their value.
That's good news because then there may be hope that the Chrome API will let SDBG do at least a drop-to-frame.
Some of these features also work in IDEs using SDBG or plain IntelliJ. For example conditional break points just work in IntelliJ, but you have to use JS expressions as you are debugging JS and not Java (how should the IDE dynamically convert a any possible Java expression to a JS expression on the fly as the browser debugger only understands JS ?!). Never tried the drop-to-frame feature but I guess it might also work.
The IDE should be able to do this just as it does it for any other language it debugs. You don't have to provide your Java inspection expressions in JVM byte code, either. I know little about the exact GWT compiler architecture; yet, I would assume that it should be possible to give the compiler enough context such that it can translate an expression into the equivalent JavaScript. It does so during normal and during incremental compilation, so at least theoretically this should also be possible when debugging. The expression compiled this way could then be passed to the native debugger's API for dynamic evaluation.
By the way you would have the same issues with any language compiling to JS, not just GWT. The only exception might be Dart as there is a Dart VM for Chrome. But once you have compiled Dart to JS you are probably in the same situation as with GWT if you need to debug the JS code and use source maps.
This, IMHO, just goes to show that the integration between the IDE debugger and the JS browser runtime is not yet where it should be. If I run a JVM external to my IDE, even when running on a remote host, the debug API allows me to do all the things discussed before. It would be interesting to check how this works for other JVM-targeted languages (Jython, JRuby, Scala, ...). I know that in the early days of Scala Martin Odersky's team had similar trouble while trying to stay with the regular JDT in Eclipse. Debug stack frames revealed compiler internals and name manglings. It wasn't nice. It required significant investment into particularly the debugging environment to reach par with JDT for Java. I guess, lack of a similar investment is what we're observing now with SDM.
-- Axel
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment