Friday, August 22, 2014

GWT i18n updated to CLDR-25

GWT has an amazing mechanism to localise Applications. It uses CLDR and ICU4J as source data to generate it's own java stuff so as it can be used in both: client and server sides.  Server side is a work on progress, and is partially functional, probably the entire implementation will be released with GWT-3.0.0 in during 2015-Q1.

The thing is that GWT internationalisation stuff has not been updated for more than 2 years since its main maintainer left Google,  remaining with the CLDR release-21 while latest is v25.

I became a GWT maintainer after I joined Vaadin some months ago, and one of the parts I maintain is internationalisation.
The good news is, that some time ago, we have been working on updating this stuff, adapting migration scripts and fixing issues.

Finally and thanks to the hard work of gwt maintainers and googlers, we have updated GWT with CLDR-v25, you can take a look to the big patch at the gwt git repository. I hope we can maintain GWT updated to last CLDR changes from now.

You can use the new stuff using latest 2.7.0-SNAPSHOT, until a new version of GWT is released at the end of September.

Tuesday, June 10, 2014

Vaadin: a way to being Productive with GWT.

I have been an active contributor to GWT for the past years, along with other open source projects such as Apache James, and Jenkins. During this time I have come to love GWT as an abstraction layer to JavaScript and a productivity booster.

When I first saw Vaadin I was a bit sceptical: Could the server-side model have even something more to offer? To find this out I decided to re-write one of my peeves, the UI of Hupa in Vaadin and see how it compares to the GWT only version.

Hupa is the webmail of Apache James. It was developed entirely in java, and for the UI we use pure GWT stuff: MVP (Model-View-Presenter pattern), Activities and RF (Request Factory).

So my idea to learn Vaadin, was to re-use the hupa-server backend and create an entire UI implementation using the Vaadin framework.

This was part hobby and part my introduction to Vaadin as a new employee at the company (I now work as a GWT expert at Vaadin).

Friday, July 6, 2012

The new GWT 2.5 closure compiler

Although GWT 2.5.0 has not been officially released yet, the release candidate has been uploaded to central maven repositories.

GWT 2.5.0 comes with many useful features, and one of them is that the compiler produces  much less code than in the previous version.

I've re-compiled two Talkwheel applications (desktop and mobile) with the new version, and without changing a single line of code, I've got a 20% of reduction ! .

But one of the hidden features in the new GWT is that gwt guys have added a new experimental compiler which reduces a bit more the size of javascript. The compiler is the well known google closure compiler which compiles from javascript to javascript producing a better code,  not only compressing the code but checking the syntax and variable references, removing death code, etc.

I've been experimenting with it and I've got a reduction of a 25% on the projects I mentioned, which  improves the normal GWT compiler in a 5%.

What I've done as well, is to compare the size of the compressed js in both cases, and surprisingly the code produced by the closure code compressed is bigger than the gwt one.
This is not a big issue since the difference is just an 1%, but it demonstrates how the gwt compiler prepares the output so as it is optimized for compression, this was a nice feature introduced in 2.0.

I've been playing with these applications compiled with the default and the closure compilers, and I've not realised any noticeable difference in performance.

Finally, If you are using maven and you want to enable the closure compiler you can either: wait until gwt-maven-plugin 2.5.0 is released, or use this workaround in your pom.xml file:

  <style>OBF' -XenableClosureCompiler '-XenableClosureCompiler</style>
Note the single quote, it works in linux and mac, but in windows maybe you have to replace them with double quotes.

Tuesday, June 21, 2011

Enabling Desktop Notifications in IE with chromeframe

Chrome comes with interesting features to improve the user experience. One of them is the 'Desktop Notifications', which allows you to display nice notifications in your desktop using javascript.

Gmail was one of the first applications making use of it, but there are many other applications like Talkwheel using it.  These applications are able to detect when the user is running chrome and they offer a link to the user to enable the feature.

Unfortunately there are many companies which only permit the usage of IE in their desktops, if this is your case, don't worry, there is a nice project called chromeframe which embeds the chrome engine in IE as an extension, making IE render faster, perform better when executing javascript, and adding many html5 features like canvas, svg, etc.

A last problem, is that chromeframe has a bug which prevents to show the info bar to authorise websites to use notifications, so you have to follow these steps to enable  notifications in IE:
  • Open IE and Install chromeframe from this URL, if you did not it before.
  • Add the entry below to your windows registry. You can do either, import the key by clicking over this link, or run 'regedit' and add the entry by hand as is shown in the screenshot below.   

  • Now you can open the chrome settings page just typing: gcf:chrome://settings/content in the url box.

  • Finally you have to enable notifications.

It seems that FireFox will support 'Desktop notifications' soon, since it is part of the html5 specification, in the meanwhile you can install the ff-html5notification plugin by clicking on this link.

Saturday, January 22, 2011

GwtQuery CSS Selectors Performance

Lately I've been working on the gwtquery opensource project, a rewrite in Gwt of the popular jquery javascript library.
Like jquery, which helps javascript developers to handle DOM elements and events, gquery helps java developers to do the same, and both share the same API with almost the same methods and behaviour.

One of the most powerful features in jquery is the ability to select elements using css selectors. In this matter, gquery improves the performance using two gwt techniques:
  • Generating permutations and selecting the more suitable engine selector for each browser .
  • Being able to analyse the css selector at compile-time and optimize the generated code.
Based on these, Gquery generates the most appropriate strategy for each browser, not only considering performance but the final javascript size.

One of the tasks I've faced along this time working with gquery, is to improve the performance of selectors adding new engines, testing them, and choosing the faster one for each browser.

There is a benchmarking application in gwtquery to compare the performance between each engine implementation. It is inspired in the Slickspeed test, taking from it the list of selectors to compare and the DOM document.
I have run this benchmark in several combinations of browsers and operating systems, and finally I have put the results into a spreadsheet to easily compare it and generate some charts.


  • I have used the browsers most used nowadays, and the operating systems I have in my virtualbox machines.
  • I have selected a bunch of the most popular javascript frameworks (jquery_1.3.1, dojo_1.4.3, prototype_1.6.0.3) and javascript selectors (sizzle_1.0, domassistant_2.7).
  • Gquery can run in two modes, gwt_compiled meaning that the compiler is able to parse each selector used in the application and generate optimized js code, and gwt_dynamic which evaluates selectors in runtime time like the rest of libraries.
  • In browsers where native optimizations are not available, Gquery falls back to a pure JSNI implementation based on Sizzle.
  • During my testing, I realised that there are browsers performing worse than others, so I had to make three groups, and each group has a different time scale to easily see the results.
  • Newer IE8 releases comes with a native selector which is only available in standard mode.
  • The unit used in all tables and charts is the millisecond, meaning the accumulated time spent to run each single slickspeed css selector.

Comparison between frameworks

This table shows the results of my tests. As you can see, gwtquery in compiled mode always beats, and in general gwtquery dynamic performs better than any other library.

Comparison between browsers:

This table demonstrates that there are browsers performing better than others. In general, opera, chrome, safari and firefox-3.6 handle DOM selectors very well, firefox-3.0 and IE8 (in standars mode) performs acceptable, and other versions of IE performs quite bad.


  • GwtQuery in compiled mode is the faster javascript library to select dom elements.
  • GwtQuery dynamic selectors are, in most cases, faster or equal than any other library.
  • GwtQuery performs better than its brother jQuery.
  • Sizzle is faster than other libraries, this is the reason why gwtquery fall back js implementation is based on it.
  • The javascript produced by the Gwt compiler performs well, and normally better than the javascript written by hand.
  • There are considerable differences between the performance of different browsers. The most significant is the behaviour of IE, although last changes introduced in IE8 are promising.
  • Gecko browsers perform worst than browsers based on webkit, nevertheless the version used in FF-3.6 has many improvements.