Do you actually use DevMode? :) It's really slow as it is, especially if you make heavy use of RPC. Granted, it's orders of magnitude faster than doing even a -draftCompile, but the "benefit" starts to wear away the more frequently you have to hit F5.
And the general plugin problem is pretty big too. Quite a few people are complaining about it. :( What if the compiler had a DEBUG output mode that cached "compiled" .js files (on the filesystem) that correspond to each original .java? If the corresponding .js "classes" were .prototype-based, it seems you could eval() changed classes into the javascript engine on-the-fly. An approach like this might let us get rid of all the various GWT.isClient/ProdMode/Script detection that happens within GWT (maybe we'd still need a .isDebug()-type method). This means that all the subtle incompatibilities between prod & demode go away because everything is running in javascript. Little things like Date handing and regular expressions come to mind. I'm just thinking out loud here, but it seems that the "instant" refresh problem could be solved in a few ways. And regarding doing Java Evaluations via the debugger, yes, you'd have to compile the expression into javascript that fits whatever is currently running, but since GWT already has a compiler, it seems this is basically a solved problem. But it's worth considering how often GWT users actually use the debugger abilities of demode. Personally, I probably set 5 or 6 breakpoints per week to debug some weird event handing bug. Otherwise, I'm just using devmode. Anyways, just food for thought... eric On Tue, Oct 4, 2011 at 3:25 AM, Ray Cromwell <[email protected]> wrote: > > We've considered it, but all of the benefit of DevMode (avoiding recompile) > goes out the window. If you change code, you have to recompile, so the whole > edit-refresh cycle takes a lot longer. > If you really just want source-level debugging of compiled GWT apps, this > can be done with > SourceMaps: http://code.google.com/p/google-web-toolkit/wiki/SourceMaps > With sufficient integration with the IDE, you could hook up a Firefox or V8 > external Javascript debugger, reverse-map any Javascript position to source > Java/Line Number, and have the IDE show that line. You could forward-map > break points to the correct JS breakpoint setting (although this may require > turning off optimizations to prevent making the entire program 1 single > line). This is all pretty straightforward and has been done for Closure > Compiler already. The real difficulty is dealing with Expression Evaluation, > if you evaluate a Java expression in the debugger, it would have to be > 'compiled' on the fly to JS. > -Ray > > On Mon, Oct 3, 2011 at 3:39 PM, Eric Ridge <[email protected]> wrote: >> >> Not real fresh, but still edible... >> >> I send the below to the [email protected] list last >> week, but I can't find a link to it via groups.google.com. Maybe it >> got held for moderation? >> >> eric >> >> ------- >> >> Anyways, I think it's entirely possible. >> >> Here's the solution -- ditch the plugins entirely. >> >> Instead, develop a Java applet that functions as a JPDA server that >> knows how to translate the state of the running GWT app into the JPDA >> protocol so a remote Java debugger can understand it. The applet >> would be embedded into the module's primary .html page. >> >> The concept of "devmode" basically goes away and instead the GWT >> compiler would have a "DEBUG" output format which would include code >> that passes state information to the JPDA Java applet as the >> javascript executes. >> >> Have youse guys considered anything like this? The JPDA applet is >> just a SMOP, but I'd have to guess adding a "DEBUG" output format to >> the GWT compiler would be pretty big. "F5/Refresh" performance would >> need consideration in this too. >> >> It's a totally half-baked idea right now, but I wanted to toss it out >> to see if the smarties at google think it's worth further thought. >> >> >> On Mon, Oct 3, 2011 at 6:22 PM, Tomasz Gawel <[email protected]> wrote: >> > Fresh idea. >> > and what about implementing debugger in an applet? :) >> > >> > -- >> > http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
