Development Mode will not be supported in Firefox 27+

22702 views
Skip to first unread message

Brian Slesinsky

unread,
Feb 3, 2014, 7:01:41 PM2/3/14
to google-we...@googlegroups.com
Mozilla has stopped exporting some C++ symbols that the Firefox plugin relies on [1]. Therefore it's not possible to support Development Mode in any new versions of Firefox starting with 27.

As a workaround, I am doing one last release to get the plugin working again with Firefox 24.2 (and hopefully newer point releases on the ESR track). If you wish to continue to use Development Mode on Firefox, you will need to download this version from Mozilla [2]. For more details see the issue tracker [3]. 

Long-term, the plan is to improve Super Dev Mode.

I apologize for the late notice; when I said at GWT.create that Firefox could stop working with any release, I didn't expect it to be the next one.

- Brian


Cristiano Costantini

unread,
Feb 4, 2014, 2:05:16 AM2/4/14
to google-we...@googlegroups.com
Hi Brian,

I wonder how does it works the development mode plugin?
Isn't it possible to replace it with something in pure javascript that is based on Web Sockets?

Yesterday I was making some test with this technology (see https://github.com/cristcost/gwt-websocket) and it it seems it has good support at least on latest Chrome, Firefox and IE (Safari don't works but I've not investigated deeply why). For the server side, I used the Jetty 7 WebSocket implementation.

I would enjoy to have a look a the code but GWT src is big, could you please tell where to look for if I would like to study the feasibility of this idea?


Debugging in Eclipse the Javascript code is one of the most important aspect of using GWT for me and I would be happy if it is possible to save it.

Cristiano




2014-02-04 Brian Slesinsky <skyb...@google.com>:

--
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-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/groups/opt_out.

Thomas Broyer

unread,
Feb 4, 2014, 4:16:14 AM2/4/14
to google-we...@googlegroups.com


On Tuesday, February 4, 2014 8:05:16 AM UTC+1, Cristiano wrote:
Hi Brian,

I wonder how does it works the development mode plugin?
Isn't it possible to replace it with something in pure javascript that is based on Web Sockets?

No, because we need blocking I/O, synchronous communication with the DevMode code server.

Leif Åstrand (from Vaadin) tried something using synchronous XMLHttpRequests, but even synchronous XMLHttpRequests are going to disappear.

The only solution would be to use the remote debugging protocols so you can really pause the execution in the browser while you do things in Java. I had started a proof of concept using the Flash Debugger to connect to an Adobe AIR runtime a while ago, could be used as a starting point if you want; but connecting a remote debugger (or using the debugger APIs from an extension) generally disables the browser's dev tools (at least it's the case in Chrome, don't know about Firefox).

Debugging in Eclipse the Javascript code is one of the most important aspect of using GWT for me and I would be happy if it is possible to save it.

The idea going forward is to use SourceMaps and remote debugging from the IDE, leveraging the same IDE code (and effort!) as for other "compiled to JS" languages (CoffeeScript, etc. or even just JS with a minifier or js2js compiler)

Cristiano Costantini

unread,
Feb 4, 2014, 4:38:34 AM2/4/14
to google-we...@googlegroups.com

No, because we need blocking I/O, synchronous communication with the DevMode code server.

mmm, good point...
can we just block with a while?
 
The only solution would be to use the remote debugging protocols so you can really pause the execution in the browser while you do things in Java. I had started a proof of concept using the Flash Debugger to connect to an Adobe AIR runtime a while ago, could be used as a starting point if you want; but connecting a remote debugger (or using the debugger APIs from an extension) generally disables the browser's dev tools (at least it's the case in Chrome, don't know about Firefox).

I'll take a look.

Cristiano
 

Thomas Broyer

unread,
Feb 4, 2014, 4:54:29 AM2/4/14
to google-we...@googlegroups.com


On Tuesday, February 4, 2014 10:38:34 AM UTC+1, Cristiano wrote:

No, because we need blocking I/O, synchronous communication with the DevMode code server.

mmm, good point...
can we just block with a while?

Because JS is single-threaded, you'll never know when to break out of the while.

Cristiano Costantini

unread,
Feb 4, 2014, 4:57:11 AM2/4/14
to google-we...@googlegroups.com
webworkers?


2014-02-04 Thomas Broyer <t.br...@gmail.com>:

--

Jens

unread,
Feb 4, 2014, 5:02:05 AM2/4/14
to google-we...@googlegroups.com
Anything people can look into to improve SDM performance? For example is it still worth it refactoring generators to be incremental generators or does the upcoming incremental compile of GWT does a better job at the end and it would be better to take a look at other things to improve SDM?

I think it would be great to have plan written down or at least very well organized issues in the bug tracker so that more people can work on improving SDM. With Firefox 27 not supporting DevMode and Chrome can break any time in the next months it may take too long for Brain alone to make SDM more useful.

-- J.

Cristiano Costantini

unread,
Feb 4, 2014, 5:01:15 AM2/4/14
to google-we...@googlegroups.com
looking at the docs of webworkers and even them don't share any state, so it won't work it too...
Anyway it would be great to find a workaround that don't require either Flash or browser plugin or Java Applet...


2014-02-04 Cristiano Costantini <cristiano....@gmail.com>:

Thomas Broyer

unread,
Feb 4, 2014, 5:33:35 AM2/4/14
to google-we...@googlegroups.com


On Tuesday, February 4, 2014 11:01:15 AM UTC+1, Cristiano wrote:
Anyway it would be great to find a workaround that don't require either Flash or browser plugin or Java Applet...

Flash or applets wouldn't work, because a) they're going asynchronous too (Flash at least) and b) they can't get access to the internal APIs we need in DevMode plugins to make them work (and that have just been removed in Firefox 27); basically knowing the lifecycle of JS objects so we can send a message to the DevMode code server to free the corresponding Java objects/references and reclaim memory (but there might be other things we need).

As I said, using the debugger APIs/protocols could work, except again for detecting JS objects "finalization" (maybe if one day we see WeakRef in JavaScript, but it's not there yet).

No, really, the way forward is better tooling for SuperDevMode to provide a similar experience to DevMode (i.e. never leave the IDE), and even allow setting breakpoints and do step-by-step within JSNI.

Cristiano Costantini

unread,
Feb 4, 2014, 6:05:30 AM2/4/14
to google-we...@googlegroups.com

No, really, the way forward is better tooling for SuperDevMode to provide a similar experience to DevMode (i.e. never leave the IDE), and even allow setting breakpoints and do step-by-step within JSNI.

Oh if this is possible than I'm ok, I was thinking that with SuperDevMode I would had been obliged to debug and breakpointing on browser development tools.
Then I need to have a look at it. 

...and yes if that is possible I agree that it is the way forward.

Ümit Seren

unread,
Feb 4, 2014, 8:52:18 AM2/4/14
to google-we...@googlegroups.com
Playing devil's advocate here: 
I code in IntelliJ but I must say that I really like the experience that the Chrome Developer Tools are providing. 
From pure debugging point of view (stepping through the code) I actually prefer the Dev Tools over the IDE because with the Dev Tools I can easily change CSS styles, modify the DOM and see the results directly in the browser. 
Furthermore Chrome Dev Tools has some really good performance and profiling tools built in. 

There are a couple of pain points of course and things I would like to see changed. 
- Bi-directional breakpoints:  Currently if I want to set a breakpoint I have to do it inside Chrome Deve Tools. It would be nice to be able to set the breakpoint in my IDE and then debug inside Chrome Dev Tools and vice versa. 
- Sometimes Dev Tools crash or freeze (if you debug a huge project) or try to display an array with many values. 

Wayne Rasmuss

unread,
Feb 5, 2014, 8:45:39 AM2/5/14
to google-we...@googlegroups.com
I second the bi-directional breakpoints idea. That's the biggest pain point for me with SDM. It stinks to track down some code in your IDE then have to track it down again in your browser to set the break point. If I didn't have to do that, I wouldn't miss debugging in the IDE much.

Kirill Prazdnikov

unread,
Feb 6, 2014, 4:03:35 AM2/6/14
to google-we...@googlegroups.com
Does the Chrome expose any kind of debugging interface so that any front-end IDE can use and visualize it ?

Thomas Broyer

unread,
Feb 6, 2014, 4:04:54 AM2/6/14
to google-we...@googlegroups.com

On Thursday, February 6, 2014 10:03:35 AM UTC+1, Kirill Prazdnikov wrote:
Does the Chrome expose any kind of debugging interface so that any front-end IDE can use and visualize it ?

Ed

unread,
Feb 7, 2014, 3:33:20 PM2/7/14
to google-we...@googlegroups.com
Usage example of the chrome debugger (not as part of the Chrome browser): Wienre: http://people.apache.org/~pmuellr/weinre/docs/latest/
(A very nice tool btw for controlling your DOM on a mobile device)

Thomas Broyer

unread,
Feb 9, 2014, 1:33:40 PM2/9/14
to google-we...@googlegroups.com
Remote debug works great too ;-)

Ed Bras

unread,
Feb 9, 2014, 1:49:54 PM2/9/14
to google-we...@googlegroups.com
Remote debug works great too ;-)
Yes, if you have a Mac ;)      (I assume you mean Safari remote debugging ? Else let me know, device independent (iphone, android))

Thomas Broyer

unread,
Feb 9, 2014, 6:40:04 PM2/9/14
to google-we...@googlegroups.com
I don't have a Mac. Chrome remote debug works great cross platform (tested with Chrome for Android, on Linux and Windows; should work w/ Chrome for iOS AFAICT). Firefox for Android (and FirefoxOS) should too (though I haven't tested it)

sabi...@hotmail.com

unread,
Feb 17, 2014, 1:48:41 AM2/17/14
to google-we...@googlegroups.com

well. no more gwt for me then, until mozilla gives google access again. downgrading the browser(either by using chrome or an earlier version of firefox) is not acceptable for me. but i can wait. got lots of non-google projects to work on.

Aleksander Gralak

unread,
Feb 18, 2014, 4:30:50 AM2/18/14
to google-we...@googlegroups.com
That is pretty bad information for all GWT developers.
For now I can stick with FF 24.2, however in the future we need to develop on the most up to date browsers.

When do you estimate Super Dev Mode will be production ready? If it is more then 6 months then we should think of some workaround. Is is possible to do a custom build of FF with all necessery symbols exported? According to

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731

they have switched it off. But if someone (sorry I am not C++ developer so I will not do it myself) can build GWT development version with those symbols. Then we would be able to do development for several more months on the latest browser and wait till Super Dev Mode if fully functional.

Jeff Evans

unread,
Feb 19, 2014, 11:37:01 AM2/19/14
to google-we...@googlegroups.com
Can someone clarify what is meant by "fully functional" for Super dev mode?  In my view, debugging the client-side GWT code in the IDE debugger, alongside server-side Java code, is the "killer feature."  I can't believe anyone would ever consider in-browser Javascript debugging to be an acceptable replacement.  Or perhaps I'm missing something?

Brian Slesinsky

unread,
Feb 19, 2014, 1:03:15 PM2/19/14
to google-we...@googlegroups.com
Super Dev Mode works and we have many teams that use it. The Chrome debugger is quite good and I recommend learning it well; anyone working on web apps will benefit from knowing this tool. For other browsers, adding a GWT.debugger() call to the Java code and recompiling is an easy way to stop in the right place. I discussed other workarounds in my GWT.create talk [1].

It's an unfortunate transition and this experience is not as smooth as it could be yet, but that's where we are.

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

Jeff Evans

unread,
Feb 19, 2014, 2:55:23 PM2/19/14
to google-we...@googlegroups.com
On Wednesday, February 19, 2014 1:03:15 PM UTC-5, Brian Slesinsky wrote:
Super Dev Mode works and we have many teams that use it. The Chrome debugger is quite good and I recommend learning it well; anyone working on web apps will benefit from knowing this tool. For other browsers, adding a GWT.debugger() call to the Java code and recompiling is an easy way to stop in the right place. I discussed other workarounds in my GWT.create talk [1].

It's an unfortunate transition and this experience is not as smooth as it could be yet, but that's where we are.


Thanks, this presentation looks useful.
 

Ed Bras

unread,
Feb 19, 2014, 2:56:59 PM2/19/14
to google-we...@googlegroups.com
 The Chrome debugger is quite good and I recommend learning it well;
It depends on your project. I been down this road, tried it several times with several projects (few months ago last one). 
Currently the Super Dev mode is "Hello World ready", but not "Enterprise ready"

With new projects, I like to start with Super dev mode, but when it becomes bigger... I am forced to jump back to FF/Chrome plugin usage.

Using it with bigger code base makes it slow and a code puzzle in chrome debug. 
For bigger projects, Chrome debugger should offer more IDE features that make debugging easy and friendly, just like we are used to using IDE tools like Eclipse.
Of course this will change, and I hope this will be soon..

m...@touk.pl

unread,
Feb 20, 2014, 3:49:42 AM2/20/14
to google-we...@googlegroups.com
Couldn't agree more... debugging the client-side GWT code in the IDE debugger (Eclipse in my case) is base of my every day work :(

Thomas Broyer

unread,
Feb 20, 2014, 5:57:30 AM2/20/14
to google-we...@googlegroups.com


On Thursday, February 20, 2014 9:49:42 AM UTC+1, m...@touk.pl wrote:
Couldn't agree more... debugging the client-side GWT code in the IDE debugger (Eclipse in my case) is base of my every day work :(

I'm sure the SDBG devs would love to hear your feedback ;-)
 

m...@touk.pl

unread,
Feb 20, 2014, 9:23:04 AM2/20/14
to google-we...@googlegroups.com


On Thursday, February 20, 2014 11:57:30 AM UTC+1, Thomas Broyer wrote:
I'm sure the SDBG devs would love to hear your feedback ;-)
 

SDBG has a long way to come (it is still in proof of concept stage, there is no support for other browser then chrome), nether the less what else we can do but to help them.

bruciadmin

unread,
Feb 21, 2014, 4:10:46 PM2/21/14
to google-we...@googlegroups.com
This is a pretty important change for me - looks like it's a downgrade to FF 26 a workaround is found. I had never heard of Super Dev mode but sounds like it's still got a fair way to go - and right now I need to focus on ROI for my work (retooling in the last 90% of a project is not an option with given deadlines).

Benjamin Bitdiddle

unread,
Feb 25, 2014, 2:47:53 PM2/25/14
to google-we...@googlegroups.com
Would anyone like to follow up the last comment on the bugzilla thread, where a FF dev claims that:

Most C++ JSAPI usage in extensions can in fact be replaced by a combination of privileged script and the debugger APIs

I assume we wouldn't be seeing this thread if that was really true as you guys would have just updated the plugin.

Brian Slesinsky

unread,
Feb 25, 2014, 3:08:48 PM2/25/14
to google-we...@googlegroups.com
I'm not sure there's much to discuss. Firefox 27 is already released, and we do want to move off of Dev Mode sooner or later for other reasons. I don't feel comfortable asking them to bring back an API that they never officially supported anyway and it seems unlikely that they'd agree. Running Firefox 24 seems like an acceptable workaround.

Regarding the Firefox-specific debugger API's, I'm not sure it's worth even figuring out if it's feasible or not since our plan is to move to Super Dev Mode. But if someone wants to take a look then go ahead.

- Brian



--

joerg.h...@googlemail.com

unread,
Feb 27, 2014, 7:51:45 PM2/27/14
to google-we...@googlegroups.com
Hi there,

I can understand that it is a hard task to maintain the GWT and especially DevMode with its plugins.
However, the hole thing about GWT is that you can do pure Java and use the Java tooling.
Developers know how to work with Eclipse. And within the Eclipse debugger you can evaluate deeply into variables and objects, add conditional breakpoints, exception breakpoints, dynamically evaluate expressions, have step filters, drop to frame, etc., etc.
I am a power user and going to SDM with chrome debugger is simply no alternative and will IMHO never be.
With GWT 2.6.0 DevMode even stopped working due to Jetty problems so I can not even use it with older FF versions.
This is a real pain for me. I am wondering if I wasted the last years building on GWT all nights (https://github.com/m-m-m/mmm/tree/master/mmm-client/mmm-client-ui/mmm-client-ui-widget/mmm-client-ui-widget-impl-web-gwt). Then I could also assimilate with JS hell and go for AngularJS.
Sorry for being so negative but I am really frustrated. Thanks for all your support on GWT (2.6.0 brings J1.7 syntax support, etc. what is really cool) and your will to improve it in the future. Maybe you can change my mind one fine day and bring me back...

Regards
  Jörg

Brian Slesinsky

unread,
Feb 27, 2014, 7:59:24 PM2/27/14
to google-we...@googlegroups.com
I'm not sure what the Jetty problems are but they should be fixed. Do we have a good bug report for them?

(In our setup we see stack traces but Jetty still runs.)

- Brian



--

Ümit Seren

unread,
Feb 28, 2014, 3:55:14 AM2/28/14
to google-we...@googlegroups.com
The Chrome Dev Tools support actually most of  eclipse's debugger features like: 
  - Evaluating deeply into variables
  - Conditional breakpoints
  - Exception breakpoints (break on uncaught exception and any exception)
  - Dynamically evaluating expressions 

Missing features are AFAIK "Drop to frame" and "step filters". 

However an advantage of SDM is that you can visually evaluate and the DOM and also inspect javascript objects (both are not really possible in eclipse).

Jens

unread,
Feb 28, 2014, 3:59:10 AM2/28/14
to google-we...@googlegroups.com
you can evaluate deeply into variables and objects,

You can do that in Chrome 
 
add conditional breakpoints,

You can do that in Chrome 
 
exception breakpoints,

You can do that in Chrome 
 
dynamically evaluate expressions,

You can do that in Chrome 


So the most important things are covered. Maybe you should just give it a serious try ?

-- J.

 


Nagin Kothari

unread,
Feb 28, 2014, 8:22:03 AM2/28/14
to google-we...@googlegroups.com
I do not know what Jetty problem  Jörg  is talking about. I am using GWT 2.6 with FF 26 and I am able to use DevMode.


--
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-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/groups/opt_out.



--
Nagin Kothari
Co-founder,
Zilicus Solutions
www.zilicus.com

Thomas Broyer

unread,
Feb 28, 2014, 1:37:32 PM2/28/14
to google-we...@googlegroups.com


On Friday, February 28, 2014 1:59:24 AM UTC+1, Brian Slesinsky wrote:
I'm not sure what the Jetty problems are but they should be fixed. Do we have a good bug report for them?

And a small regression on something we never really actually supported: https://code.google.com/p/google-web-toolkit/issues/detail?id=8526
…and now that we're using Jetty 8, people are sking for more ;-) https://code.google.com/p/google-web-toolkit/issues/detail?id=8472

joerg.h...@googlemail.com

unread,
Feb 28, 2014, 4:48:25 PM2/28/14
to google-we...@googlegroups.com
Hi Jens,


> Maybe you should just give it a serious try ?
I already gave SDM several tries. However it never worked in my case at all. The problem is that I am not just doing a hello world with GWT but some rather complex UI framework with some special aspects. I hope that I do not appear just to be a ignorant jerk. Maybe SDM can convince me some day...
Hopefully someone can help me. I always get this:

workDir: C:\Users\hohwille\AppData\Local\Temp\gwt-codeserver-8835691028753667732.tmp
log4j:WARN No appenders could be found for logger (org.eclipse.jetty.util.log).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
binding: user.agent=safari
binding: compiler.useSourceMaps=true
binding: locale=en
Compiling module net.sf.mmm.app.Mmm
   Validating units:
      Ignored 17 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
   Finding entry point classes
      [ERROR] Unable to find type 'net.sf.mmm.app.client.Mmm'
         [ERROR] Hint: Check that the type name 'net.sf.mmm.app.client.Mmm' is really what you meant
         [ERROR] Hint: Check that your classpath includes all required source roots
[ERROR] Compiler returned false
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
    at com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:128)
    at com.google.gwt.dev.codeserver.ModuleState.<init>(ModuleState.java:58)
    at com.google.gwt.dev.codeserver.CodeServer.makeModules(CodeServer.java:120)
    at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:95)
    at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:71)
    at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:49)

This is all confusing:
> Unable to find type 'net.sf.mmm.app.client.Mmm'
That is actually my entry Point and it is available in the m2e project from that I run the SDM. Also didn't GWT say the following so it should have already found the type:
> Compiling module net.sf.mmm.app.Mmm
Also confusing:
> Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
IMHO there is no such option for com.google.gwt.dev.codeserver.CodeServer
> [ERROR] Hint: Check that your classpath includes all required source roots
I am using m2e in Eclipse and my codebase is VERY modular. Maybe that is the source of the problem.

Any help would be highly appreciated...
BTW: I found some workarounds for my Jetty problem and can at least run DevMode with FF 26 on 2.6.0 now.

Regards
  Jörg

Thomas Broyer

unread,
Mar 1, 2014, 10:33:36 AM3/1/14
to google-we...@googlegroups.com
That's the module (gwt.xml), which references the entry point.

How are you launching SDM? Using M2E or just a “Java application” Eclipse launch configuration? How is it configured?
 
Also confusing:
> Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
IMHO there is no such option for com.google.gwt.dev.codeserver.CodeServer

That's right.
 
> [ERROR] Hint: Check that your classpath includes all required source roots
I am using m2e in Eclipse and my codebase is VERY modular. Maybe that is the source of the problem.

Maybe, maybe not. Hard to tell without knowing more about the way you launch SDM.

(also: maybe better to start a new thread, for others that could search the group archives in the future)

Joseph Lust

unread,
Mar 4, 2014, 4:36:41 PM3/4/14
to google-we...@googlegroups.com
I'm surprised more folks are not excited to jump ship to SuperDevMode. 

I'd argue Eclipse DevMode is more pain than it's worth. Certainly, it is very cool to have your backend and frontend breakpoints set and hit on the same screen. Yet I've spent a lot of time trying to all of the Run Configurations setup properly. Have a multi-module project? Have an OSGi project? Trying to debug a remote server? Working with JSO's? It's a bit of trial and error and not always possible. Startup is slow. Recompile is even slower and it's a memory hog, crashing with OutOfMemory more than I'd like. Plus, you need a ring of chicken blood around your computer to ward of breakages with new browser upgrades.

Enter SDM. I open one console type mvn tomcat7:run-war. I open a second and run mvn gwt:run-codeserver. No need for configuration settings windows and embedded Jetty's. No need to even have an IDE at all! Personally I find simpler, imperative tooling much easier to use and troubleshoot. Add to this Chrome Dev Tools will be a full fledged IDE soon at the rate they're adding features and FF Dev Tools have also come a very long way since FireBug.

Finally, don't we want the GWT team to spend their time building new features rather than keeping old tooling alive in the ICU? I think GWT's hit an inflection point where dumping IE everything and DevMode would free up a lot of resources. Many projects never make such painful decisions and become dinosaurs for it. I hope GWT does not.

Sincerely,
Joseph

Ed Bras

unread,
Mar 4, 2014, 4:50:19 PM3/4/14
to google-we...@googlegroups.com
> I'm surprised more folks are not excited to jump ship to SuperDevMode. 
I think because many dev peeps use GWT for enterprise projects.....(and they should of course)...
And for bigger projects, SDM is (still) hard to use (as explained in this post, and I "really" tried/used it several times).
Really hoping this will change soon...


Thomas Broyer

unread,
Mar 4, 2014, 5:34:36 PM3/4/14
to google-we...@googlegroups.com
And as a corollary, Enterprise culture has a HUGE resistance to change. There are people out there still using GWT 2.4 (more than 2 years old already!) or even older versions. The problem is with these people and that culture; most of the time they chose GWT (and webapps) for bad reasons, and fall into the Enterprisey over engineering trap that makes GWT painful to use (bloated apps). They have to change, they have to update their tools and move forward, or quit doing Web dev.

Ed Bras

unread,
Mar 5, 2014, 3:30:54 AM3/5/14
to google-we...@googlegroups.com
> They have to change, they have to update their tools and move forward, or quit doing Web dev.
Agree, that's why I spend a lot of grey hairs in using SDM, but it's simple not there yet saidly... Don't get me wrong, I wish it would as I certainly see the advantages.

I noticed that it's hard to understand these reasons by people that have their focus on "Hello world" app's or hardly touch enterprise alike GWT app's...

BTW: for none enterprise app's, I use others JS frameworks like JQuery.
GWT: heavier business logica (= call it Enterprise app's or some other beautiful trendy name), share with backend...

Just my 50 cents to have a good understanding what we talk about..

Thomas Broyer

unread,
Mar 5, 2014, 4:15:55 AM3/5/14
to google-we...@googlegroups.com


On Wednesday, March 5, 2014 9:30:54 AM UTC+1, Ed wrote:
> They have to change, they have to update their tools and move forward, or quit doing Web dev.
Agree, that's why I spend a lot of grey hairs in using SDM, but it's simple not there yet saidly... Don't get me wrong, I wish it would as I certainly see the advantages.

And don't get me wrong: I'm not saying SDM is either perfect nor 100% usable yet. I was just reacting to the fact people complain that DevMode won't be maintained anymore as they don't *want* to move to SDM (which is entirely different from your “I tried, it didn't work” situation).
We're currently in a transition period where DevMode is already half-dead and SDM isn't 100% usable yet. Hopefully SDM should be much better by the next release, with incremental compilation (that'll have an impact on your code to really take advantage of it).

James Wendel

unread,
Mar 27, 2014, 10:58:00 PM3/27/14
to google-we...@googlegroups.com
My company got screwed by using GXT2 with gxt-uibinder library that broke with GWT 2.5 due to compiler changes. We've been stuck on GWT 2.4 for that reason as we had 100+ .ui.xml files to convert to pure java. We finally did the work, but it was definitely a painful lesson.

Thomas Broyer

unread,
Mar 28, 2014, 6:22:48 AM3/28/14
to google-we...@googlegroups.com

On Friday, March 28, 2014 3:58:00 AM UTC+1, James Wendel wrote:
My company got screwed by using GXT2 with gxt-uibinder library that broke with GWT 2.5 due to compiler changes. We've been stuck on GWT 2.4 for that reason as we had 100+ .ui.xml files to convert to pure java. We finally did the work, but it was definitely a painful lesson.

I hope the lesson is to avoid relying too much on hacks (particularly when coming from a third party).
(been there, done that)

Ed Bras

unread,
Mar 28, 2014, 6:34:26 AM3/28/14
to google-we...@googlegroups.com
Can't agree more. Same experience, even contributed to mygwt (previous name of GXT)... 
The nice thing about GWT: making easy/fast small lib's, is also a risk; not being maintained..

dhoffer

unread,
Mar 28, 2014, 9:21:59 AM3/28/14
to google-we...@googlegroups.com
Could you elaborate on how you have your POM setup?  I'm trying to make the switch to SDM but I get errors running run-codeserver.  Your setup seems ideal I'd like to know how you have both of those things configured.  Not sure it matters but I use IntelliJ instead of Eclipse...DM worked great.

-Dave

Juan Pablo Gardella

unread,
Mar 28, 2014, 10:14:23 AM3/28/14
to google-we...@googlegroups.com
Hello James, 

after replace ui.xml by pure javadoes the application compile faster? I thought ui.xml views increment a lot the compiler time.

Juan


2014-03-27 23:58 GMT-03:00 James Wendel <jmwe...@gmail.com>:
My company got screwed by using GXT2 with gxt-uibinder library that broke with GWT 2.5 due to compiler changes. We've been stuck on GWT 2.4 for that reason as we had 100+ .ui.xml files to convert to pure java. We finally did the work, but it was definitely a painful lesson.

--

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

Jérôme Beau

unread,
Apr 2, 2014, 5:05:07 AM4/2/14
to google-we...@googlegroups.com
Hi Thomas,

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.

By non-mature, I mean a SDM that lacks features DM had, such as Java-level inspection (inspecting Java values of Java variables). I am amazed that nobody complains about this loss. Even if you achieve proper support for debugging in SDM from the IDE, will it allow such Java-level inspection ? I doubt it, you'll only allow JS-level inpections, while allowing Java-level stepping, which does not fit the GWT promise of keeping at the Java level. This is the reason why most of GWT developpers use it.

Aleksander Gralak

unread,
Apr 2, 2014, 5:30:52 AM4/2/14
to google-we...@googlegroups.com
Do not agree. A lot of people complain about it. 


--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe.
To unsubscribe from this group and all its topics, 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.

Jens

unread,
Apr 2, 2014, 6:47:45 AM4/2/14
to google-we...@googlegroups.com
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.


-- J.

David

unread,
Apr 2, 2014, 9:05:22 AM4/2/14
to google-we...@googlegroups.com
For me it will depend how well SDM works with IE because that is the main browser that I need to support. Not all GWT applications are put on the internet and in an enterprise environment (more specifically banking) IE is still king. It will already be a big battle to get them to move to IE9 or preferably IE10 or newer.
 
I could use FireFox/Chrome in dev (and I do actually) but I need to often debug in IE because of issues that only happen there and with SDM that can be 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-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.

Thomas Broyer

unread,
Apr 2, 2014, 9:33:43 AM4/2/14
to google-we...@googlegroups.com


On Wednesday, April 2, 2014 3:05:22 PM UTC+2, stuckagain wrote:
For me it will depend how well SDM works with IE because that is the main browser that I need to support. Not all GWT applications are put on the internet and in an enterprise environment (more specifically banking) IE is still king. It will already be a big battle to get them to move to IE9 or preferably IE10 or newer.
 
I could use FireFox/Chrome in dev (and I do actually) but I need to often debug in IE because of issues that only happen there and with SDM that can be painful.

AFAICT, for the time being, and for the coming year(s?), DevMode will still be supported in IE. Specifically because IE Developer Tools aren't really developers' friends and don't support Source Maps.

Jérôme Beau

unread,
Apr 2, 2014, 9:57:55 AM4/2/14
to google-we...@googlegroups.com
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? 

Ümit Seren

unread,
Apr 2, 2014, 10:26:50 AM4/2/14
to google-we...@googlegroups.com
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. 



--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe.
To unsubscribe from this group and all its topics, 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

unread,
Apr 2, 2014, 10:47:24 AM4/2/14
to google-we...@googlegroups.com
A lot of negative feedback (maybe ) has been going for SDM. It seems a little harsh to my eyes so here is my positive 2 cents.

We are using SDM for a new project which started from zero lines but grows up pretty fast. We are importing older (even non GWT) modules and 3rd party projects with a fast pace. So far we are at 15-20kloc (sloccount) and the SDM compilation doesn't really slows us down. Of course we do tricks with remote filesystems and ssh-tunels to run the compiler in faster machines than our older developer machines. But the fact that we able to pull such tricks is evident to me that the technology is sound and simple enough for me to understand it. I have to admit that the DM with the plugin business I never understand it enough so I could explain it to my co developers. The SDM is pretty straight forward.

Of course I wouldn't say no to improvements in compile time (currently 8sec for me - but may vary up to 30sec) in my i5 with 8G machine.

On another note I have to say that SDM triggered some old memories of mine. The way the debug happens in the browser reminded me my first days in computing with x86 debuggers where we were trying to match the compiler output (assembly) to the higher level C input (yes I know - source maps). I am not really using the debugger in my every day life to watch variable values so this feature was not a big enough loss for (and can be emulated by looking at the assembly ^H^H javascript variables).

However what I find indispensable is the browser's debug tools. Why css is not applied? It is overrided? Who override it? Why width: 100% means 83px? Where are my other 2 pixels? Where is the padding? What the padding is doing here?

And of course flow related questions like: Exception? From where? From here? I thought it was an event listener? Aah the mouse events are also triggering the event listener. What do you know...

And for this the browser's debugging tools (chrome and (not or) firefox) are good enough ^H^H best admittedly with some brain assisted mapping.

So far SDM represents a win for me

   Vassilis Virvilis



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

Jens

unread,
Apr 2, 2014, 11:11:30 AM4/2/14
to google-we...@googlegroups.com


Am Mittwoch, 2. April 2014 15:57:55 UTC+2 schrieb Jérôme Beau:
Hi Jens,

Just for the record : do you agree that using SDM you cannot inspect Java values of Java variables in your browser?

Yes thats true. The only Java code you see in the browser is the Java source file provided via source maps. Everything else is JS based because you are debugging JS and not Java.

 
if I debug JS, I expect to have JS inspections ;

Thats what you do with SDM debugging. The only difference is that the browser helps you to figure out which line of code in your source language (in this case Java) maps to that specific piece of JS you are currently debugging. 
SourceMaps is not about making the browser understand Java code. You should not expect the browser to understand something like "e.getMessage().equals(MyErrorsEnum.CONSTANT)" in a conditional break point. The browser simply does not know how to execute that string.

 
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.

Thats what you do with classic DevMode + browser plugin. In this situation you never really leave the JVM which could also mean that you never really spot an issue in your code because it might only occur in pure JS after the app is compiled. That already happened to me: Clients report errors but in DevMode you can not reproduce them just because you are using DevMode.


Is there a tiny possibility that GWT can provide this in some future? 

I think there is some work going on for IntelliJ and Eclipse to use the browser remote debug connection to get JS from the browser and then use source maps inside your IDE. And maybe, just because this now happens inside an IDE, that IDE is then able to do some more work to provide you a more Java'ish feeling while debugging.

For example take a look at: https://github.com/sdbg/sdbg as a proof of concept in Eclipse.

-- J.

Jérôme Beau

unread,
Apr 2, 2014, 11:35:37 AM4/2/14
to google-we...@googlegroups.com
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. 

Brian Slesinsky

unread,
Apr 2, 2014, 1:04:33 PM4/2/14
to google-we...@googlegroups.com
It's true these are disadvantages.  There are some compensating advantages that people are pointing out: the code executes faster, it works with remote websites where latency is higher, it works with mobile phones, and so on. But there's no question that losing DevMode (other than IE and Firefox 24) is a loss.

Our short-term plan is to speed up compiles and generate JavaScript that looks more like Java for Super Dev Mode and draftCompile. But it it will still be JavaScript, and we will have to adjust. Longer-term, it may be possible to create a variable inspector that shows Java objects instead of JavaScript objects, but that isn't even prototyped yet.



Slava Pankov

unread,
Apr 2, 2014, 3:26:42 PM4/2/14
to google-we...@googlegroups.com
DevMode is working just fine in Firefox 26 (not 24). And probably will work till Firefox ESR becomes 27 (it's only 24.4 now). So there is a time frame for normally working DevMode at least till the end of 2014. I hope SDM will be much better then.
What I'm concerned about that GWT team don't broke DevMode in 2.7 and 3.0 releases. Also it would be really nice to ask Mozilla team return back needed functionality for DevMode (but allow/enable it only if you run Firefox with specific command line parameters). I think it's completely possible to talk to them and explain the situation, nobody benefits from the situation, when GWT developers are refusing/disabling Firefox updates after 26 version.