Hi Ümit, By "I cannot inspect Java values of Java variables" I mean that the source-mapping of the Chrome Dev Tools (which are good for JS) :
- *shows me stuff I'm not interested into *(most of the time) : "this" is "Window[0]", DOM, JS or internal GWT-generated functions or properties appear, such as "$H", "___clazz$", "getClass$", "hasCode$", "toString" & "toString$", "attached", "eventsToSink", "proto", etc. -* renames stuff I'm interested into* : "MyClass" becomes "MyClass 0" "1", etc. "this" becomes "this$static" - *doesn't allow me to skip only in my code by defaut*, that is, automatically skip "internal", gwt-generated code while stepping - *doesn't allow me to use Java-expressions in breakpoints nor evaluations*: have to use JS string.length, not String.length() for instance, etc. You know, this just like when you debug plain Java code. Most of the time, you are not interested in debugging JDK sources. This may be interesting for understanding things and optimization (if you forget that's only draft JS code that will _not_ be the final code), but this is disabled by default. One might also consider than inspecting bytecode is good for understanding and optimization, but that's not reasonnable. Le mercredi 2 avril 2014 16:26:50 UTC+2, Ümit Seren a écrit : > > What exactly do you mean with "I cannot inspect Java values of Java > variables" with SDM ? > Can you provide an example where you can't inspect a Java value with > Chrome Dev Tools ? > > I think Dev Mode will never come back. SDM is here to stay and despite > there is a lot to be desired, with time development experience will be much > better than with normal Dev Mode. > > The Chrome team is putting huge amounts of work into improving Chrome Dev > Tools. > The profiling features are crucial if you want to create performant web > apps and I prefer to do all task (profiling, fiddling with DOM/CSS and > debugging) right in the Chrome Dev Tools rather than switching between > Chrome Dev Tools and my IDE. > > For those who really need the features of their IDE there are some efforts > to bring sourcemap debugging to eclipse (AFAIK IntelliJ has already support > for it built in) > > The biggest issue with SDM are currently compile times but that's going to > improve with the incremental compiler in GWT 2.7. > > > > On Wed, Apr 2, 2014 at 3:57 PM, Jérôme Beau <java...@gmail.com<javascript:> > > wrote: > >> Hi Jens, >> >> Just for the record : do you agree that using SDM you cannot inspect Java >> values of Java variables in your browser? I agree about the mobile dev, >> about knowing the underlying web platform, about everything but... any >> debugging session, Java or JS, have to be consistent : if I debug JS, I >> expect to have JS inspections ; if I debug Java (even in the browser >> through sourcemaps), I expect to see Java values and Java symbols, and I >> expect that my conditional breakpoints occur on Java expressions, not JS >> expressions. That's it. Otherwise I would have used a JS framework. >> >> Is there a tiny possibility that GWT can provide this in some future? >> >> >> Le mercredi 2 avril 2014 12:47:45 UTC+2, Jens a écrit : >> >>> I just realized that lack of Firefox 27+ support for dev mode recently >>>> (tried it because Chrome's plugin crashed too often) and really think this >>>> is a shoot in the foot for GWT : even if you don't control Mozilla choices >>>> of course, forcing to move to a non-mature SDM is very risky for GWT >>>> itself. >>>> >>> >>> But there is no other viable solution and the transition was actually >>> planed more smoothly. I can understand that many people can not use SDM >>> just because the SDM compilation is too slow for their project. But I don't >>> understand people saying that debugging with SDM is a pain. Yeah for a Java >>> developer it is strange to leave the IDE but honestly for every day >>> debugging browsers provide everything you need. There may be some hiccups >>> here and there but overall it is useable and it is not at all comparable to >>> the situation around the time GWT was invented. Back in these days "use >>> your Java debugging tools" was a very strong argument but today browsers >>> have catch up and will continue to catch up. If GWT will provide debugging >>> in IDEs with SDM then it is only for convenience. >>> >>> You must become a web developer even if choosing GWT and you should >>> understand the browser platform sooner or later just like you need to >>> understand Swing when doing Java Desktop apps. >>> >>> I think the most risky thing of GWT proper was to ignore mobile too long >>> and now it has to catch up quickly. With this in mind, SDM is actually a >>> huge plus for GWT because it enables you to build/debug mobile apps more >>> easily. With DevMode only, developing mobile apps is painful. >>> >>> >>> >>> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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.
