I've been using GWT now since about version 1.3. I chose it at the time because I really liked the manifesto and in particular the line "Java debugging is non-negotiable" (see http://www.gwtproject.org/makinggwtbetter.html). I admire folks who live without a debugger. Maybe they have the rigor to write code that simply doesn't require it. Or they have most of their code reside on the server, as one of the fellows wrote above. Or they have client code that for other reasons does not have to perform complicated tasks, maybe because the application is simple in its requirements.
However, when these factors are not given (and the GWT architecture has helped and guided us to exploit a lot more of the powerful browser platforms by shifting significant elements of our applications to the client), having a powerful debugger is a tool that makes me much more productive in my work. Features that I subsume under "powerful" are in particular (in decreasing degree of importance to me) - instant expression inspection (Eclipse: Shift-Ctrl-i to inspect the expression you just marked; works even on hover over fields and stack variables) - conditional breakpoints (provide a boolean expression and break if true; or break upon reaching an invocation count which I don't use that often) - drop to frame (after meticulously moving to where the problem is, hitting F6 one time too often...; no problem with drop to frame) - dynamically altering field and variable values (makes for a powerful couple in conjunction with drop to frame as it allows me to play "what if") Inserting print statements may work for some. It doesn't if that code is a library that isn't easy to change. I don't want to have to unpack all sources first only in order to get "conditional breaking." Apart from that, the SDBG / GWT 2.7 combo is really "surprising" at times when I do an F6 to step over a line or expression and I end up in some Iterator or Collection implementation because that's how that for-loop is actually happening. Also, the subtle differences in behavior of F6 for multi-line statements between native Java/JVM and SDBG/SDM debugging increasingly annoy me. For Java, F6 goes to the next line, e.g., in a multi-line expression embedded in a statement. For SDM, F6 executes the entire statement. Bad luck if what you wanted to check was in the third line of your three lines long statement (and there is no drop to frame, either...). It really takes some getting used to and to me feels far from usable for my every-day work. I really appreciate the speed that SDM provides. I've been using it since more than a year now, also together with SDBG in Eclipse. The incremental compile works like a charm, even when radically switching branches. There are clearly benefits in having the browser's JavaScript engine execute "the real thing" instead of running the client in the JVM and then having the costly browser integration that in several dimensions doesn't feel "real" (performance and stability, mostly). I also understand that browsers have changed in ways that make maintaining the existing DevMode plugin impossible. With that being said, I'd really love to reattain the level of productivity that I perceive with DevMode when it comes to debugging. SDBG just doesn't even come close to what I consider a real debugger. Stepping and watching variables is just by far not enough by today's IDE standards. I'm not an expert in native browser's JavaScript debugger capabilities. What keeps SDBG from providing the above list of features? If the compiler can map expressions to JavaScript, why can't SDM map those same expressions to something that the native JavaScript debugger can evaluate in-place for the current stack frame? Don't native JavaScript debuggers support conditional breakpoint? It would also come down to injecting the compiled expressions as breakpoint conditions. Don't native JavaScript debuggers support drop-to-frame? If not, can we expect this to change in the future? And what about the dynamic value changes in a native JavaScript debugger? Removal of DevMode without adequate improvements in SDM as outlined above, despite the promises of further performance improvements beyond 2.8, could be a valid reason to never upgrade beyond 2.8 anymore and keep a good old FF or IE version around that helps us with the heavy-lifting of debugging when it is really required. Best, -- Axel (sapsailing.com) -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
