GWT 2.6.1 release coming soon!

The GWT team recently published it’s second release candidate for the 2.6.1 version. The gwt maven plugin project kept up and published RC releases as well.

The GWT RC2 can be downloaded directly from the following URL, and through the maven central repository.

http://storage.googleapis.com/gwt-releases/gwt-2.6.1-rc2.zip

Unfortunately, I could not find any release notes at the gwtproject.org site (as it did for past RC versions). That is why I am publishing the changes/ fixes since release 2.6.0 here:

  1. 39c29e0  Workaround for webapp classloader regression in DevMode by Thomas Broyer - 3 weeks ago
  2. b3ab3b7  No longer reference SVN in modules generated by WebAppCreator by Thomas Broyer - 7 days ago
  3. 6e233ec  Added suppress warnings for DOMImplStandard#dispatchEvent* by Goktug Gokdogan - 9 days ago
  4. b936d92  Fix non determinism in code generation. by Roberto Lublinerman - 3 months ago 2.6.1-rc1
  5. b106664  Restore support for derived DataResource in @url CSS extensions by Lukas Laag - 4 weeks ago
  6. 2ca906f  Deprecates HttpThrowableReporter in favor of JsonLogRecordClientUtil. by Goktug Gokdogan - 3 weeks ago
  7. 9c9acb6  Fix UnusedImportRemover to traverse package annotations by Thomas Broyer - 3 weeks ago
  8. 5ab60ad  Fixes RichTextArea.Formatter.insertHTML for IE permutation by Goktug Gokdogan - 5 weeks ago
  9. 2734df5  Don’t fail compilation if we can’t emit a private artifact by Thomas Broyer - 4 weeks ago
  10. eccdfb4  Update Guava to 16.0.1 for CDI compatibility by Thomas Broyer - 9 weeks ago
  11. dd26380  Fix inconsistency in MethodInliner. by Roberto Lublinerman - 4 weeks ago
  12. dbf6b1c  Default softPermutationId to 0. by Stephen Haberman - 3 months ago
  13. 7863f3e  Windows compatibility for SuperDevMode by Thomas Broyer - 8 weeks ago
  14. 4298446  NPE in UnusedImportsRemover when processing files without definitions. by Roberto Lublinerman - 3 months ago
  15. eaec824  Strengthen SuperDevMode test in selection script by Thomas Broyer - 9 weeks ago
  16. b5f0284  Fix erroneous boxing of primitive return values by $entry() by Thomas Broyer - 2 months ago
  17. b646c3a  Restores old interface for GWT Designer. by John Stalcup - 3 months ago
  18. 61ed5fd  Fixes regressions in @UiHandler. by Goktug Gokdogan - 3 months ago

 

GWT closing panel

The last session in the gwt.create conference was a discussion panel with speakers, GWT steering committee members and participants asking questions.

panel

Here some questions/ answers I managed to write down…

Q: What about Dart, GWT, say in two years?

The point is: GWT is here to stay, and even if Dart becomes the real next huge big thing, GWT will be one way to do it. Daniel reiterates that we should not think of one OR another.

Q: We don’t want to debug in JS in Chrome. Any way to do it better then SuperDevMode?

Well, no. DevMode is going away, and that is not GWT teams fault. Browsers are closing the door to required plugins, JS debuggers and source maps are the way to go.

SuperDevMode is no replacement or DevMode, but it has advantages, hence we start debugging in the target language/ platform. Besides, SuperDevMode is the only way to debug on mobile devices.

We also must take the improvements made by browsers/ debuggers in the past, so there is hope. IntelliJ is working on a remote debugger, nothing is known about Eclipse.

Attendees stated real life issues with SuperDevMode and the thread posed by not having DevMode ready, stable, fast, usable by the time the plugins stop working.

Discussion also showed that adoption might be better if setup is easier. Still, the worst case as described by Ray would be that we cannot use DevMode in the newest browsers – specifically Firefox and Chrome. We must keep in mind that actually DevMode is already broken in Safari and mobile devices.

Q: If you had a magical wand, what would you add/ remove change from GWT?

Nice question, here some statements.
Please don’t take them seriously, as no one really does have a magic wand…  :-)

  • Remove UI binder in favor of a HTML template mechanism
  • Incremental building
  • Vertical and Horizontal Panels (attendees cheer…  :-)  )
  • Kill the Widget system (because it was original made to fix IE6 memory leaks) in favor of a light widget model
  • Remove the “Serializable” interface support for GWT-RPC, as the implications on compilation are huge
  • Add runtime performance. More. Performance.
  • Configuration properties, compiler properties. Properties confusion.

jQuery for GWT without jQuery

gQuery is a purely GWT port of jQuery, this way taking all advantages of the GWT compiler.

The main purpose is to enhance UI elements:

gQuery can also be used to create completely new HTML based widgets, while still providing the full widget component interface.  This allows us to create lightweight widgets and repeat less code by using the core functionality provided by the library. Another very interesting part is that, by being entirely written in  GWT,  the compiled code will include only the pieces that were used.

Further, gQuery offers a set of functions very useful and missing in the core GWT distribution:

Like its counterpart, gQuery provides a plugin system. Existing plugins can be found here.

Beyond DevMode – the future of GWT debugging

The days of the GWT DevMode are counted. Why? Because DevMode relies on a native browser-plugin to work (that approach was introduced with 2.0 and was called  OOPHM, out of process hosted mode). Those browser plugins rely on the C++ NPAPI, which will be deprecated on chrome by the end of 2014. Safari has already disabled NPAPI support (and thus broken DevMode on the Mac + Safari setup). To make things worst, mobile devices never offered such an native API.

Having its days counted, a future solution must be found. The new solution is not new and have been around for while: the SuperDevmode. And interestingly, this solution will work with mobile devices too. So while not new (and there are a few good blog posts documenting how to set it up), there are a few things that me must know.

First, we switch over to Javascript debugging. To keep things readable, GWT provides source maps, but Chrome is the only browser where you can use them. Firefox and Safari are meant to support source maps someday, but it is not working as of today as stated by Erik Kuefler.

Secondly, IntelliJ is already working on a remote debugger solution that will probably be released soon. So if you are looking for a tighter IDE integration for future GWT development, it seems like IntelliJ is the IDE of choice.

While the new approach is promising when it comes down to JavaScript to Java end to end debugging, it feels like a huge step backwards when you are used to  debugging tools in Java development.

 

TURDUCKEN – How to handle big GWT projects?

How do you split big GWT projects?

A pattern used internally by Google (e.g. by adwords) was presented by Rob Keane and carries the name TURDUCKEN, which comes from “TURkey DUck chiCKEN”, that pretty much describes the approach…

turducken

When tackling big applications, you can either go for the monolithic one module approach, or try to split the application into many smaller ones with separate entry points, breaking the “single page” principle.

  • One module problems: one release, one build, very large if split not working, hard to test.
  • Many modules problems: full page reload, no split possible at all

According to Rob, at the end, multiple GWT modules is the only way to go… but how to handle page reloads?

The TURDUCKEN approach describes a surrounding global container, the first thing to load.  This way we still have a global single page GWT application that only reloads parts (submodules), providing a custom global shared place in the global container. For example,  the container could handle the overall history and the submodules containing their own entry points.

When a module should get loaded, you add the required script tag to load the corresponding module. All modules live then in the same container.

  • The container provides the main UI management, modules not going for the root panel anymore
  • CSS should avoid global style names (@external) to avoid conflicts (change body ID if you really need @external and must avoid collisions)
  • Introduce a custom history handler that does not change the URL directly, but propagates history changes via events to the container

To make inter app communicaton possible, you must create a global event bus hosted in the global container. This global event bus must be accessed via a JSNI based wrapper, wrapping and unwrapping of events must be implemented properly. One approach could be introducing GWT auto beans to serialize objects being passed back and forth between modules through the container.

Introducing a TURDUCKEN approach depends on number of teams, application size and submodules structuring. Most important: when using the actual common approaches typical to GWT rich client development, moving into such an TURDUCKEN approach should be possible.