Getting rid of Dev mode for future GWT releases

[Liraz S]

I get that this is impossible to keep maintaining the previous Dev mode, but without it GWT cannot be debugged properly anymore.

See the following for example:

http://stackoverflow.com/questions/25105469/how-to-debug-using-superdev-mode

In SDM You cannot watch, it's impossible to check which type or what's the problem exactly during debug - it basically made working with GWT impossible.

The only thing that helps me get going with GWT development is the regular Dev mode - which you can use the full features of debugging, and solving the problem in seconds - not hours

And as far as i can see, this will not be improved anytime soon - since Chrome is simply translating source maps, it's not debugging a JVM program - and will be the same for all other browsers that will support source maps.

Oh.. and what about IE? will they support source maps - you just killed it there i guess..

You have to get the Dev mode back, and to make the legacy Dev mode better - not the super dev mode that is aimed to source maps - i think it's a mistake.

Super dev mode is a nice idea and feature, but it doesn't work - tried it for some time...

Also tried it on 2.8.0 - still useless.. same problems - far from the basic needs of debugging

[Jens]

Debugging using SuperDevMode is different but definitely not impossible. It also doesn't cost hours spotting a problem. Eclipse users often use the Eclipse plugin "SDBG" which allows you to debug your JavaScript code in your IDE: https://sdbg.github.io . IntelliJ users can do that out of the box.

To be clear: Old DevMode will not come back because Firefox / Chrome do not provide the required NPAPI anymore. And regardless of how often that topic will be discussed here the situation for Firefox / Chrome will not change. 

I think you can still use old DevMode in IE and of course in older versions of Firefox / Chrome, but no further work will be invested in old DevMode. Thats why it has been officially deprecated for the GWT 2.8 release.

Instead work should be invested in improving the SourceMaps spec so the target language (in case of GWT its JavaScript) can be hidden more and more during debugging.

-- J.

[Thomas Broyer]

On Wednesday, December 9, 2015 at 7:35:38 PM UTC+1, Liraz S wrote:

You have to get the Dev mode back, and to make the legacy Dev mode better - not the super dev mode that is aimed to source maps - i think it's a mistake.

It's not going to please you but 2.8 will be the last release still shipping with DevMode. It'll be removed from 'master' as soon as we cut a release/2.8 branch (the patch has been ready for weeks/months on Google's side, it's only waiting for 2.8 to be branched out)

[Ed]

I love DevMode, I will miss it :(

Super DevMode, not Super enough for me... (tried it a few times with bigger apps, got lost in the chrome sources, takes too much time...)

[Kirill Prazdnikov]

Hi Liraz,

I get that this is impossible to keep maintaining the previous Dev mode, but without it GWT cannot be debugged properly anymore.

I can debug apps in SDM, I can set Java breakpoints on code and on exceptions. It works for me under IDEA + Chrome.

 

See the following for example:

http://stackoverflow.com/questions/25105469/how-to-debug-using-superdev-mode

In SDM You cannot watch,

 

I can watch members and locals. Yes they have a bit different names, but I can inspect objects.

 

it's impossible to check which type or what's the problem exactly during debug

Type of a variable ? use sout v.getClass() 

- it basically made working with GWT impossible.

And as far as i can see, ... , it's not debugging a JVM program - ...

There is no JVM when JS executes, so that there is nothing to debug in JVM.

 

You have to get the Dev mode back, and to make the legacy Dev mode better - not the super dev mode that is aimed to source maps - i think it's a mistake.

Consider using GWT 2.7, it supports DevMod

-Kirill

[Frank]

I am always amazed how hard some people rely on debuggers.
I almost never use any breakpoints or things like that. Maybe because in my early years you just did not have any debuggers at all.

I find SuperDevMode more than enough and I am using it for over more than a year and never missed DevMode. On the contrary, I love the speed SuperDevMode gives me.

[Dennis Haupt]

it depends on how you work.

i have worked in situations where debuggers added no benefit (aka many automated tests), but also some where they really turned hours into minutes because you could simply directly look into the computers brain instead of pondering about what might have gone wrong (feeding your software with new/unexpected data that made it do strange things)

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

[Vassilis Virvilis]

+1

+ you can compile/test/debug on mobile browsers

I am using breakpoints very rarely and merely as tool to inspect and undrestand the underlying system. Are they events firing? Are they firing too much? print statements are usualy enough to debug my program logic.

I mean most of the program logic is on the server anyway in my case. Do you have most of the logic in the client?

     Vassilis

--

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

--

Vassilis Virvilis

[steve Zara]

SDM takes some getting used to, but now I wouldn't want to go back to Dev mode.  The real advantage I have found with SDM is the ability to debug a large codebase in reasonable time - startups for Dev mode can be very slow.  Source maps are now supported pretty much everywhere, and work very well in Chrome.  I used to complain about SDM but I can honestly say that after months of use I found it a reasonable way to debug.  Not perfect, but it did mean that I could debug graphics-intensive code in reasonable time, which was just not possible in Dev mode.

[Ed Bras]

Interesting discussion about breakpoints ;)​

It all depends on your situations and requirements...

I don't like breakpoints but need them:

1) Solve a problem quickly instead of reading the code for hours (like mentioned).

2) Easily understand the flow (stack) without setting many print stuff.

3) Improve performance: loops that are done to much, code that is called too much, which can be a burden with big data (you don't want to wait till productions runs with bigger data then in test)....

....

Just my 50 cents...

[Ed Bras]

Thanks for sharing @Steve. Good to read that you do have "ok" experience with larger codebase.

> SDM is the ability to debug a large codebase in reasonable time - startups for Dev mode can be very slow.  

I am always surprised when people say this.

 run a code base of total more then 2.5MB total (after compilation in soyc report), pretty fast on windows and mac. Startup in about 5-8s. When developers came to work on the project they ware always surprised it starts fast.

Maybe it's because I debug for performance ;-)

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/IfLWnnCf9rM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[steve Zara]

Sorry, I was mistaken - what I meant was the ability to debug a combination of large code and data.  Some of my applications transmit many megabytes of encoded data to the client.  The decoding of this data is very fast in native javascript but extremely slow in Dev mode.  This is why my application startups in Dev mode can be very slow.  I can get a certain state of code + data loaded much faster in Super Dev mode - indeed, this was my main reason for switching.

[Ed Bras]

@Steve: thanks for sharing your experience, good to know.​

When I have some more time the next coming month I want to try again Super DevMode, I really would love to use it. It's just easy not to use it when you work a lot and the DevMode works fine in my case...

[Frank]

If you have to read code for hours to solve a problem without a debugger I think you have some bigger problems with your code than some bugs... (code structure)

[Ed Bras]

@Frank: you are absolutely right, but it's difficult to generalize this, as it highly depends on your situation.

I have seen hello-world kind of code that was very easy to understand, but also very complex, but very clean code to meet a lot of financial (security) requirement, or code with many visitor patterns to be able to handle different kind of products (subclasses). In these latter cases, it can cost you a lot of time to understand, even when it's very clean and good coding....... Often analyzing the code cost more then making the change... (according to statistics: solving bug consists 70% of code/issue analyzing).

On 10 December 2015 at 18:01, Frank <frank....@gmail.com> wrote:

If you have to read code for hours to solve a problem without a debugger I think you have some bigger problems with your code than some bugs... (code structure)

--

[geek.m...@gmail.com]

I don't know why this is such a controversial topic. The debugger is just another tool in the developer's toolbox. I'm a huge proponent of TDD, and when you get code with a high percentage of code coverage, I hardly ever go into a debugger. There are other times when, even when all incidental complexity is removed from a code base, there is enough intrinsic complexity that when things break, its faster to just go and look what is really being returned by a function, or the order of events. A debugger is really good for that.

Heck a debugger is a good tool to learn about a new framework - set some breakpoints in code you don't yet understand and step through it until you understand it.

So - my opinion - reducing the functionality of the debugger (moving from DevMode to SDM, for example) is in fact a loss of useful features and a reduction in the power of the tools at my disposal. I can use SDM - but it only covers like 50% of the functionality I use in a JVM debugger.

On Thursday, December 10, 2015 at 12:29:53 PM UTC-5, Ed wrote:

@Frank: you are absolutely right, but it's difficult to generalize this, as it highly depends on your situation.

On 10 December 2015 at 18:01, Frank <frank....@gmail.com> wrote:

If you have to read code for hours to solve a problem without a debugger I think you have some bigger problems with your code than some bugs... (code structure)

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/IfLWnnCf9rM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Peter Donald]

On Saturday, 12 December 2015, <geek.m...@gmail.com> wrote:

So - my opinion - reducing the functionality of the debugger (moving from DevMode to SDM, for example) is in fact a loss of useful features and a reduction in the power of the tools at my disposal. I can use SDM - but it only covers like 50% of the functionality I use in a JVM debugger.

 

I keep hearing that SDM is not as good as DevMode but our experience is that it is better in almost every way. This may be because we IntelliJ idea.

In Both you can run the debugger from the ide, set break points, inspect variables. DevMode has the advantage that variables are easier to decipher. SDM has the  advantage of speed for both startup and refresh and during debug. SDM also never has to deal with differences between different modes and can debug regular JavaScript / other is languages

The one disadvantage will surely be fixed in time so I never really understand why people lament the imminent demise of DevMode

--
Cheers,

Peter Donald

[Evan Ruff]

This topic has been beaten to absolute death. 

DevMode is dead because Chrome and Firefox killed it, nothing the GWT Team or Steering Committee or anybody else could control.

If you need the breakpoints in the IDE, spend the $150 for IntelliJ and get on the SuperDevMode train.

E

[David]

I was reluctant at first to move over to SDM, but after some time with it, I got used to it. I combine it with SDBG in eclipse and it works mostly ok. 

I don't need to go in the debugger that often and the moments that I really needed it with the old Dev Mode was because of some browser specific issues anyway. For the rest I try to focus as much as possible on unit testing. Only some special cases are hard to handle with SDM but these are really are. 

What SDM brings is much faster prototyping of the GUI, especially in combination with Thomas Broyer's maven plugin it's really nice to have both server and client refresh so easily while developing. 

--

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-tool...@googlegroups.com.

To post to this group, send email to google-we...@googlegroups.com.

Visit this group at https://groups.google.com/group/google-web-toolkit.

[Ed Bras]

I was reluctant at first to move over to SDM, but after some time with it, I got used to it. I combine it with SDBG in eclipse and it works mostly ok. 

What is exactly not woking well with the SDBG eclipse plugin?

And why is this working well in IntelliJ ?

What SDM brings is much faster prototyping of the GUI, especially in combination with Thomas Broyer's maven plugin it's really nice to have both server and client refresh so easily while developing. 

How do you use the maven plugin to speed this up ?

 

[DavidN]

On Friday, December 18, 2015 at 10:17:27 AM UTC+1, Ed wrote:

I was reluctant at first to move over to SDM, but after some time with it, I got used to it. I combine it with SDBG in eclipse and it works mostly ok. 

What is exactly not woking well with the SDBG eclipse plugin?

And why is this working well in IntelliJ ?

Sometimes it works, sometimes it doesn't that is a bit annoying. Some constructs like for loops were not properly mapped to the java sources which made stepping through them a bit painful. But I am running behind on SDBG, I did not do GWT development in the last year - just starting again.

In Chrome I do not always seem to get the mapping to work for all classes in my project.

I have no experience with IntelliJ, but I am interested in using it since maven/eclipse integration seems to be really slow and buggy. But I am forced to use ClearCase for the moment and we don't have IntelliJ support for it. I hope we can switch to something git based next year.

What SDM brings is much faster prototyping of the GUI, especially in combination with Thomas Broyer's maven plugin it's really nice to have both server and client refresh so easily while developing. 

How do you use the maven plugin to speed this up ?

I just launch tomcat and codeserver from maven instead of depending on my IDE. It works really well. Any change I make to server classes gets loaded automatically by Tomcat and any change on client code gets picked up by the SDM codeserver. In the browser I just click on reload and I have the latest version, it takes just a second or 2. (OK I seem to have an issue with GWT 2.8.0-beta1, but I'm sure that will get resolved somehow).

 

[Ed Bras]

Good to know, @DavidN, thanks for sharing...

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/IfLWnnCf9rM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[N Troncoso]

Can you like.... explain a little more about your setup? In our production environment, our app is hosted by Tomcat, but by default GWT uses Jetty. There are some discrepancies there, and any Tomcat specific issues are super hard to debug. We've been trying to move to SDM with Tomcat, but we haven't gotten it working. Is there any special setup involved?

[Thomas Broyer]

See https://github.com/tbroyer/gwt-maven-archetypes for a simple setup using the tomcat-maven-plugin.

[Ming-Yee Iu]

I don't think it's technically impossible to keep DevMode running. I was able to get DevMode to work using JavaFx as the browser instead of Chrome, and it seemed to work ok for basic stuff. It might also be possible to port the GWT UI framework to Elemental, and I've also been able to get Elemental to run in Java on top of JavaFx. I suppose it's even possible to make special versions of Firefox or Chrome that have the features needed to support the DevMode plugin directly.

I doubt that Google sees any value in maintaining DevMode for itself though. But I imagine if you have a support contract with an enterprise software firm selling GWT stuff like Vaadin or RedHat, you could probably bug them to do the necessary work to make it happen.

[Axel]

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)

[Ed Bras]

@Axel: thanks for sharing and you are 100% spot on....

I also like to know if/how SDBG can be improved to benefit the full debugging power.... 

​

[Jens]

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?

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.

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.

AFAICT to make cross language debugging better, the source maps spec needs to be updated. Currently it seems to lack some information. For example I think it misses variable/parameter names, otherwise chrome debugger would probably show java names instead of JS names in the debugger. On the other hand it is handy that I can see JS variable names as that makes conditional breakpoints possible as I need to use JS expressions ;-)

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.

-- J.

[Chak Lai]

In the past, I had encountered situations that the code works fine under Dev-Mode, but things went wrong in production mode, or acted differently in production mode.

At the beginning I had a hard time to switch from Dev-Mode to SDM. It took me "forever" to trace the bugs in my code. I found that things got a lot easier when I start new project from the very beginning using SDM.

More Java code in the Browser-end means more stuff GWT needs to convert into JavaScript. With using SDM, it encourages me to use more HTML / CSS / JavaScript instead of using GWT-Java only.

[Thomas Broyer]

Well, except that JsInterop doesn't work in legacy dev mode.

[Axel]

 

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