Re: Getting rid of Dev mode for future GWT releases

[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 

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

Re: Getting rid of Dev mode for future GWT releases

[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.

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

Re: Getting rid of Dev mode for future GWT releases

[Thomas Broyer]

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

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

Re: Getting rid of Dev mode for future GWT releases

[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.

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

Re: Getting rid of Dev mode for future GWT releases

[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
​

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

Re: Getting rid of Dev mode for future GWT releases

[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.

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

Re: Getting rid of Dev mode for future GWT releases

[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)

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

Re: Getting rid of Dev mode for future GWT releases

[Thomas Broyer]

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

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

Re: Getting rid of Dev mode for future GWT releases

[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?

On Tuesday, December 22, 2015 at 4:45:25 AM UTC-5, DavidN wrote:
>
> 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).
>  
>

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

Re: Getting rid of Dev mode for future GWT releases

[Ed Bras]

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

On 22 December 2015 at 10:45, DavidN  wrote:

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

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

Re: Getting rid of Dev mode for future GWT releases

[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).
 

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

Re: Getting rid of Dev mode for future GWT releases

[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.

On Thu, Dec 17, 2015 at 5:48 PM Evan Ruff  wrote:

> 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
>
> On Friday, December 11, 2015 at 7:18:56 PM UTC-5, Peter Donald wrote:
>
>>
>>
>> On Saturday, 12 December 2015,  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
>>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Getting rid of Dev mode for future GWT releases

[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 ?

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

Re: Getting rid of Dev mode for future GWT releases

[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

On Friday, December 11, 2015 at 7:18:56 PM UTC-5, Peter Donald wrote:
>
>
>
> On Saturday, 12 December 2015,  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
>

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

Re: Getting rid of Dev mode for future GWT releases

[geek . macbeer]

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  
> 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+unsubscr...@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.
>>
>
>

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

Re: Getting rid of Dev mode for future GWT releases

[Peter Donald]

On Saturday, 12 December 2015,  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

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

Re: Getting rid of Dev mode for future GWT releases

[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)

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

Re: Getting rid of Dev mode for future GWT releases

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

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

Re: Getting rid of Dev mode for future GWT releases

[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


On Thu, Dec 10, 2015 at 11:39 AM, Frank  wrote:

> 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.
>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@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

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

Re: Getting rid of Dev mode for future GWT releases

[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)

2015-12-10 10:39 GMT+01:00 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.
>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Getting rid of Dev mode for future GWT releases

[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.

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

Re: Getting rid of Dev mode for future GWT releases

[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

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

Re: Getting rid of Dev mode for future GWT releases

[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...

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

Re: Getting rid of Dev mode for future GWT releases

[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 ;-)



On 10 December 2015 at 11:33, steve Zara  wrote:

> 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.
>
> On Wednesday, 9 December 2015 18:35:38 UTC, Liraz S wrote:
>>
>> 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
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Getting rid of Dev mode for future GWT releases

[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.

On Wednesday, 9 December 2015 18:35:38 UTC, Liraz S wrote:
>
> 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
>

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

Re: Getting rid of Dev mode for future GWT releases

[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.

On Thursday, 10 December 2015 10:50:26 UTC, Ed wrote:
>
> 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 the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

[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...

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

Re: Getting rid of Dev mode for future GWT releases

[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.

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

Re: Getting rid of Dev mode for future GWT releases

[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)

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

Re: Getting rid of Dev mode for future GWT releases

[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...)

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