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.
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.
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 firstname.lastname@example.org.
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.