Shared publicly  - 
 
If you're a GWT user, try to guess what is going on in this screen shot.
66
38
Emilio Bravo's profile photoBrandon Donnelson's profile photoRay Cromwell's profile photoH Ibrahim's profile photo
26 comments
 
Java source debugging on chrome dev tools? Nice ! Does it eliminate the need for eclipse?
 
Seeing what I want to see:
Chrome is tightly integrated with GWT dev mode, a plugin is no longer needed, and it is 10x faster than the FF plugin.
 
Actually +Jeff Drost, this isn't "dev mode." The "SourceMaps" spec is about letting compiled languages (GWT, Dart, CoffeeScript, etc) publish xref tables that map the JavaScript tokens to tokens in their original language so debug information for the compiled product can be associated to the original source file.

I doubt this will change the operation of the "dev mode" as it currently exists (dynamic compilation and execution from inside the JVM) anytime soon.
 
Cool too. Does this work well if you obfuscate & optimize? I'd imagine attributing a piece of JS to the source gets tricky very quickly. Can you inspect state?
 
I'd really like to see fast incremental compilation associated with this. Then I could easily debug things like WebGL apps that don't work so well in dev mode.
 
Robert is right, this is not DevMode, it is SourceMaps in action, which enables source-level debugging within Chrome DevTools, and yes, it works like with obfuscation and optimization.

+Brian Slesinsky and I are working on a "Super Draft Mode" GWT compiler spec that will eliminate the need for DevMode. Like the Dart Compiler, we will emit unoptimized separately compiled "linkable" JS. The compiler will run as a persistent server. When it notices a source file change on disk, it will load in, and re-translate that file to JS (and maybe re-run generators). It can either re-link the JS and refresh the whole patch, or just patch/eval in the new code (edit and continue)
 
+Ray Cromwell I hope that "Super Draft Mode" won't completely eliminate DevMode. Even with SM+SDM, I still like being able to run Java profilers against my GWT code. :/ I would be perfectly willing to tolerate the DevMode pain to keep that ability. The browser tools aren't bad, but I find if you need a first-pass look at what is wrong, the Java profilers are tough to beat, even if they don't necessarily reflect performance in-situ.
 
We don't have plans to eliminate dev mode, but we don't have plans to improve it except for bug fixing
 
Wow, this is awesome. When can i try it out :)
 
The SourceMap support in Chrome Dev Tools is very preliminary right now, this was actually the first test of the code, and there's lots of bugs. GWT SourceMap support is more solid and will land this quarter (e.g. a few weeks) and pays dividends in better stack-trace/logging even if Chrome isn't ready yet. If I had a guess, I'd say don't expect it to be useable for at least 2 months, the Dev Tools APIs are still in flux. Of course, since Chrome and GWT are open source, we can't really stop you from picking up interim commits and patches and trying to hack it to work. :)
 
This may be naive, but are there any plans for Chrome Dev Tools to talk to a remote debugger, perhaps with some translation/proxying to trick Eclipse into thinking of it as a JVM? So then debugging stays in Eclipse and keeps up the Java facade. Granted, it would probably take a lot of magic to make Java-looking objects for inspection/etc. But then GWT is all about magic.

Either way, "super draft mode" sounds pretty slick.
 
I believe that there is already an Eclipse project that does this (and IntelliJ can do it too), that is, debug remote JS within Chrome. Which means, all we'd need to do is patch Eclipse to know about SourceMaps.
 
Wow, I just got breakpoints fully working with this and it rocks, I can set breakpoints on GWT code, click a widget, have Chrome DevTools open the correct Java file, and step through it a line at a time, watching the UI morph as I go. Keep in mind, this will work with any language, including CoffeeScript or Dart, as long as SourceMaps are supported.
 
Awesome, can you inspect variables?
 
Not yet, that will require hooking up symbolmaps, so that when you display a variable in the Scope panel, or add a Watched variable, it maps the symbols to/from the compiled identifier. It's on the list. :)
 
This is somewhat tangential, but I really like the idea of the daemon that watches for files that change. With scalagwt, embedding scalac similar to ecj works great, except that ecj is fast enough that it can start from scratch (with a new compiler instance) on each refresh. scalac, not so much. Even 1-line changes (with the other units being cached) takes some-number-that-is-too-long seconds to compile. It's usable, but annoying.

So I had already been mulling over a) somehow reusing the same compiler instance across refreshes and b) getting files submitted as soon as the dev hits save to get a head start on the compilation. Your daemon would solve b) easily; not sure about a) as you could still build it to use a fresh ecj for each compile given it's fast enough to not matter.

Anyway, scalagwt isn't going the embedded route right now anyway, instead opting for using the user's regular IDE/CLI compiler to make jribble/class files, but that's a different tangent.
 
It works with Closure Compiler generated source too. It is amazing what information allows you too do. :-) In this case source level debugging, code size contribution analysis, and stack trace deobfuscation. I'd love to hear other ideas that people have that are enabled by source maps
 
This is music to my ears, great job!!!!.
 
+raw thinktank I think your dataset sampling is a bit small to conclude that 'all' are moving to dart.

When you say GWT is the new VB6, is that saying Java and/or Javascript are the new VB6, because the last time I looked both of those aren't even close comparison to it.
 
There's a big difference between a closed source proprietary technology like VB and GWT. GWT can't really die as long as people continue to use it, anymore than Perl, Python, Ruby, or PHP, or even libraries like jQuery, can die without some company funding them. On the other hand, if MS drops support for something, and there's no open source, that's it, the product is dead.

If Google ever abandons GWT (which they are not), the fact that it is an open source project means that anyone can fork it and continue to improve it as long as it is useful to them.

This has nothing to do with being screwed for profits. Google doesn't make money off of GWT and never did. It was an open source gift to the community that people were free to use and improve. GWT Designer, for example, use to be a commercial product from Instantiations. Google acquired this company for a large sum of money, turned around and gave the product away for free, with source code. In fact, it donated a big chunk of Instantiation's former products to the Eclipse Foundation.

I really don't understand how building your own framework from scratch changes the equation. If Google, for example, were to completely abandon GWT, it's still open source, so you can take it and modify it as you wish. Writing your own compiler and framework from scratch will take more work, rather than just forking GWT and starting off with a mature base.

We obviously don't encourage forks, and would rather merge improvements back into GWT proper, but the threat of a fork is always there if we don't serve the community well enough.
 
Direct debugging in Chrome is an Awesome idea, This would make life so much easier.
I know it's been close to 4 months since you posted the original screen shot... Really anxious to know about how this tool is being progressing.. I would love to give it a try when it comes out in a release.
Add a comment...