Schlagwort-Archive: gwt

Es ist vollbracht, es ist schnell, es funktioniert.

Die gute Nachricht zuerst: GWT 2.7.0 ist da!

Seit dem ersten Video von Daniel Kurka zum Thema SDM habe ich auf 2.7 umgestellt und alle paar Tage GWT trunk ausgecheckt, gebaut und ausprobiert. Wie in dem Video deutlich zu sehen, man bekommt man inzwischen SDM sehr einfach zum laufen.

Nach einigen Wochen SDM trauere ich dem DevMode nicht nach – die Anwendung läuft im Browser tatsächlich schneller, alles ist flüssiger und verbraucht auch nicht mehr so viele Ressourcen.

Das neue SuperDevMode erkennt Änderungen im Quelltext selbständig und beherrscht ab jetzt auch das Inkrementelle kompilieren. Nur der erste Aufruf dauert etwas länger, hier wird die komplette Anwendung einmal kompiliert.

Der einzige Wermutstropfen: wir verabschieden uns mit dem neuem SDM vom „Debuggen“ in Java, ab jetzt können wir nur noch die Debug-Funktionen des Browsers nutzen. Mit IntelliJ und Chrome kann der Browser „Remote“ aus der IDE heraus debugged werden, ist aber trotzdem nicht das gleiche.

FĂĽr besonders haarige Sitzungen ist demnach noch das alte DevMode mit einer kompatiblen Browser-Version zu empfehlen.

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.

Unfortunately, I could not find any release notes at the 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


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.


GWT as an open source project, current status

Since GWT has been open sourced years ago, GWT mainly stayed an open sourced project run by Google. This has been changed with the introduction of the GWT committee and the big move into more openness.

Matthew Dempsky shared a few insights with the current state of GWT as an open source project. GWT finally detached from integral Google build process, moved to external GIT and Gerrit as first source of truth.

The GWT „re-opensourcing“ and move to GIT started paying of. From 5% non Google patches in 2012 to actually 20% in 2013. Still rough spots in the review process, no official ownerships: only unofficial owners and un-owned code. Integration builds are still a problem, since testsuite too large, too expensive to run. Presubmit testing delivers fast response.

The build process is a work in process. The move to maven was stopped as seen as unfitting for GWT. The ant build files are working but are not good, there is some interest in gradle/ buck. Unfortunately there is no dependency management yet.

The future of GWT and web development

Vaadin is actually hosting a purely GWT focussed, not the first one, but it is a long time since we had a GWT conference, and Joonas (from Vaadin) shared some stats: we have 600+ attendees in San Francisco and in Frankfurt together, Frankfurt being sold out.

Ray Cromwell just held the keynote on the gwt.create conference in San Francisco and shared some quite interesting insights on where GWT has come from and how it is moving forward.

While GWT has it’s roots in a time where JavaScript VMs where slow and incompatible, the current state of the browsers and their JVMs is quite different.


So the main challenge in web development changed, and GWT being used so widely at Google, will move forward as well. While speed is going to improve further (Google is still working very hard on the compiler, improving split point generation, fully integration of the closure compiler and much more), the main magic (from my personal view) is happening in the JS inter-operation.

There are really many powerful JS libraries, and modern web development uses them all. The GWT team is working on seamless integration of JS libraries, from lightweight wrappers (say goodbye to JSNI and overlay types) to zero effort JS interop, where the required Java interfaces get generated auto-magically for the JS libraries you drop into your project. And best of all – those libraries should be used un-minified in development and will be parsed by the GWT compiler and get all the optimizations the GWt complier is great at. This means that you can drop the complete jQuery library into you project, but only the JS you use will find its way into your application.

The next major GWT release is expected to come mid 2014 with full Java 8 support and hopefully a bunch of the new magic demoed today.